Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-1738

CSP_Mid.CBF MCS testing and tools enhancements

Details

    • Obs Mgt & Controls
    • Hide

      An enhanced and ore comprehensive unit testing framework will increase the development and testing process efficiency, ensuring in the same time a more thorough SW verification process. 

      Show
      An enhanced and ore comprehensive unit testing framework will increase the development and testing process efficiency, ensuring in the same time a more thorough SW verification process. 
    • 3
    • 3
    • 1.667
    • Team_CIPA
    • Sprint 5
    • Hide

      The objectives of the MidCBF.MCS feature were only partially achieved because of the following factors:

      • The common Objective SPO_1234, (Updates as peADR-35) and SDR-400: this work was planned relatively late in the PI11 IP and it took longer than anticipated; this was partly due to the fact that:
        . the Mid.CBF MCS configuration json file had progressed significantly over the previous 2 PIs; the additional parameters could not be accommodated therefore we’ve been asked to revert to an older version of the configuration file; this required updates to the source code and the testing functions and additional testing in order to support both the old and the new version.
        (https://skao.slack.com/archives/C024E4X3TLL/p1624893161198500?thread_ts=1624866849.185300&cid=C024E4X3TLL)

      . The support for json (as opposed to yaml) DB configuration file, which is used by both lmc and mid.cbf, was broken and required updates by the system team.

      • The common objective SPO-1223 (Migration to CAR) : this was unplanned work for the CIPA team, which raised several challenges and further delayed our planned work for SP-1738.
      • AT5-730: Mid.CBF MCS: Add support for testing using DeviceTestContext: the original plan for this work was to adapter MCCS tools required for unit-testing in order to increase the efficiency of the development and testing process. In the meantime, since the MCCS support for unit-testing is very complex, a simplified version was created by the system team and incorporated in the ska-tango-examples. We decided to adopt this simplified version, however, this version proved to be not work as expected and inadequate for our purpose (when the code is organized in a multi-level Tango client/server hierarchy). The ska-tango-examples approach has been implemented and tested (within its inherited limits) in Vcc. The more comprehensive MCCS approach will be implemented in future PIs.
      • AT5-734 - Remove Docker dependencies and Repository directory re-structuring has been completed
      • AT5-732 - Remove unnecessary json configuration validation code has been completed.

      (For reference, slack discussion with the system and MCCS team: https://skao.slack.com/archives/CECSS44LX/p1628750545013000?thread_ts=1626482856.107700&cid=CECSS44LX)

      • AT5-760 and AT5-739 : Due to time constrains these stories have been deferred to PI12.
      Show
      The objectives of the MidCBF.MCS feature were only partially achieved because of the following factors: The common Objective SPO_1234, (Updates as peADR-35) and SDR-400: this work was planned relatively late in the PI11 IP and it took longer than anticipated; this was partly due to the fact that: . the Mid.CBF MCS configuration json file had progressed significantly over the previous 2 PIs; the additional parameters could not be accommodated therefore we’ve been asked to revert to an older version of the configuration file; this required updates to the source code and the testing functions and additional testing in order to support both the old and the new version. ( https://skao.slack.com/archives/C024E4X3TLL/p1624893161198500?thread_ts=1624866849.185300&cid=C024E4X3TLL ) . The support for json (as opposed to yaml) DB configuration file, which is used by both lmc and mid.cbf, was broken and required updates by the system team. The common objective SPO-1223 (Migration to CAR) : this was unplanned work for the CIPA team, which raised several challenges and further delayed our planned work for SP-1738 . AT5-730: Mid.CBF MCS: Add support for testing using DeviceTestContext: the original plan for this work was to adapter MCCS tools required for unit-testing in order to increase the efficiency of the development and testing process. In the meantime, since the MCCS support for unit-testing is very complex, a simplified version was created by the system team and incorporated in the ska-tango-examples. We decided to adopt this simplified version, however, this version proved to be not work as expected and inadequate for our purpose (when the code is organized in a multi-level Tango client/server hierarchy). The ska-tango-examples approach has been implemented and tested (within its inherited limits) in Vcc. The more comprehensive MCCS approach will be implemented in future PIs. AT5-734 - Remove Docker dependencies and Repository directory re-structuring has been completed AT5-732 - Remove unnecessary json configuration validation code has been completed. (For reference, slack discussion with the system and MCCS team: https://skao.slack.com/archives/CECSS44LX/p1628750545013000?thread_ts=1626482856.107700&cid=CECSS44LX ) AT5-760 and AT5-739 : Due to time constrains these stories have been deferred to PI12.
    • 11.6
    • Stories Completed, Integrated, Outcomes Reviewed, NFRS met, Satisfies Acceptance Criteria, Accepted by FO
    • PI22 - UNCOVERED

    • TDC Team_CIPA technical_debt

    Description

      The current Mid.CBF MCS consists of  multiple device servers organized in a 3-level client/server hierarchy (to which, the test functions, acting as clients, become the 4th layer).  

      At all levels, connection to subordinate device servers,  are currently performed via Tango DeviceProxy().   This renders the testing process more complex and less efficient.

      Following the testing approach  adopted in the base classes, this paradigm would have to change to establish the connections to subordinate servers rather via DeviceTestContext or MultiDeviceTestContext (which allow stubbing out the database). (https://pytango.readthedocs.io/en/stable/testing/testing_approaches.html).

      This in turns, entails using wrapper classes that can switch between the 2 types of connection for testing purposes. Such a class and other testing utilities can be adapted from the ska tango base classes and/or the ska-low-mccs project.

      In addition, the set of test function currently implemented need to be augmented  to include support for all commands/attributes in all device classes.

      Attachments

        Issue Links

          Structure

            Activity

              People

                v.mohile Mohile, Vivek
                M.Radulescu Radulescu, Michelle
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 3.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete315.0
                  Total315.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel