Further elaboration of acceptance tests for standalone SDP

Ensuring the stability of a key subsystem such as SDP is critical. Well-established testing of core functionality and interfaces (for both expected and unexpected behaviour) within the sub-system will provide stability and allow easy isolation of problems prior to integration with SKAMPI.

• Review completeness and approach to current testing of the SDP system.
• Develop additional automated acceptance tests of a standalone SDP system that include both happy and sad routes. Sad routes should include tests of 'what if' behaviour including checking that:
  • SDP interfaces provide a predictable and useful response when internal components are not available or not responding as expected.
  • SDP still behaves in a predictable and reasonable way if an external interface is provided with a request that is not expected.
• Tests should run quickly and ensure they will always provide the same results when repeated.
• Testing of at least one simple real-time (could be a sub/mock) workflow should be included, testing both expected (happy) behaviour and failure modes (sad routes).
• Create a short report providing an assessment of completeness of testing reached and steps to improve this further (including consideration for improving the use of defensive programming in the SDP components)
• Demonstrate the current level of testing, possibly both as a system demo and for review in the SS-82 task team.

The infrastructure for the tests in the SDP integration repository has been improved as part of this feature. The tests now use a TangoGQL server to control the Tango devices in the tests. This allows the test script to be executed outside the SDP control system namespace, even outside the cluster. The tests have been updated to allow them to be run in Minikube in a developer's own machine as well as in the SDP integration CI pipeline.

Some basic unhappy path tests have been added to the integration repository. They test the behaviour of the Tango devices, and verify that:

• Commands called when a device is in the wrong state are refused;
• Subarray commands called with malformed arguments fail.

More elaborate tests of unhappy paths, such as a controller or workflow failure with an appropriate response, would require SDP to have a failure-reporting mechanism that does not yet exist. (One of the potential features suggested as part of SP-1884 is to implement this mechanism.)

A test of the visibility receive workflow has also been added to the integration repository. This deploys the visibility receive workflow, sends data to it using the mock CBF sender and verifies that the data written to the measurement set matches the data that was sent.