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

Investigate mocking PyTango devices for testing

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Obs Mgt & Controls
    • Hide

      Reduced complexity of, increased reliability of, and reduced time to run unit tests of TANGO devices.

      Show
      Reduced complexity of, increased reliability of, and reduced time to run unit tests of TANGO devices.
    • Hide

      Based on discussion between Team Karoo with Giorgio and Vivek, Giorgio's resulting agreed-on suggestion: 

      1. provide well written examples of test cases in the context of the CentralNode case study that exemplify the problem of creating mocks/patches of tango devices so that we have device A that interacts with device B, and we create a mock for device B
        1. where "interacts with" means that A sends a command to B, and A reads an attribute of B, and A subscribes to change events in B
        2. and so that the examples cover all these possibilities.
      2. with code that is based on synchronous communication; let's leave asynch code for later
      3. with at least 1 example that uses also s.williams's technique based on monkeypatch (https://docs.pytest.org/en/latest/monkeypatch.html)
      4. With the TCoP coordinator write a confluence page that explains these examples.
      5. It would be good to include in these pages some of the material that was already produced wrt to DeviceTestContext.

      Initial acceptance criteria:

      • there are examples of tango devices whose proxies are mocked with pytest mock/patch, and the mocks are used to support unit testing of methods implementing commands, attributes, states of the device.
      • some mocks are designed so to support testing of methods that are called according to an event-driven approach (eg on attribute changes).
      • no interaction between tango devices is handled nor assumed by these tests.
      • no interaction with Tango database is handled either.
      Show
      Based on discussion between Team Karoo with Giorgio and Vivek, Giorgio's resulting agreed-on suggestion:  provide well written examples of test cases in the context of the CentralNode case study that exemplify the problem of creating mocks/patches of tango devices so that we have device A that interacts with device B, and we create a mock for device B where "interacts with" means that A sends a command to B, and A reads an attribute of B, and A subscribes to change events in B and so that the examples cover all these possibilities. with code that is based on synchronous communication; let's leave asynch code for later with at least 1 example that uses also  s.williams 's technique based on monkeypatch ( https://docs.pytest.org/en/latest/monkeypatch.html) With the TCoP coordinator write a confluence page that explains these examples. It would be good to include in these pages some of the material that was already produced wrt to DeviceTestContext. Initial acceptance criteria: there are examples of tango devices whose proxies are mocked with pytest mock/patch, and the mocks are used to support unit testing of methods implementing commands, attributes, states of the device. some mocks are designed so to support testing of methods that are called according to an event-driven approach (eg on attribute changes). no interaction between tango devices is handled nor assumed by these tests. no interaction with Tango database is handled either.
    • 2
    • 2
    • 3
    • Team_KAROO
    • Sprint 5
    • 5.6
    • PI22 - UNCOVERED

    • Enabler Team_KAROO goal_O3 testing

    Description

      Investigate mocking/patching to allow a PyTango device to be instantiated without actually running it in a subprocess with the TANGO runtime components.  In this case the basic behaviour of all methods could be unit tested. It would require mocking/patching the PyTango Device class, or at least SKABaseDevice, so that it does not try to call the bootstrapped libtango DeviceImpl constructors. It should still call the device under test’s init_device method but not try to connect to a TANGO database.  Obviously, if the device instantiates DeviceProxy objects to connect to dependent devices, it would useful to mock those devices’ basic behaviour too (commands and attributes).  There would still need to be integration level testing that actually runs the real devices, but the unit testing could be simplified.

      The above is suggested in Testing TANGO Controls - see the details and conceptual example in the "Future Work / Potential Solutions" section.

      Acceptance Criteria

      • there are examples of tango devices whose proxies are mocked with pytest mock/patch, and the mocks are used to support unit testing of methods implementing commands, attributes, states of the device.
      • some mocks are designed so to support testing of methods that are called according to an event-driven approach (eg on attribute changes).
      • no interaction between tango devices is handled nor assumed by these tests.
      • no interaction with Tango database is handled either.

      Attachments

        Issue Links

          Structure

            Activity

              People

                v.mohile Mohile, Vivek
                p.swart Swart, Paul [X] (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 2.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete48.0
                  Total48.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel