Interface To The System Under Test

Different systems under test will have varying levels of accessibility and will require different approaches for interfacing with them. Here are some general guidelines for interfacing with SUTs and infrastructure components, keeping in mind that in some cases, developers may need to be involved in the design and creation of interface code.

Many systems and components will already have APIs (Application Programming Interfaces) that can be used for monitoring, control, and failure injection. Utilize these APIs whenever possible to minimize the need for custom interfaces or shims. 

If a system or component does not have an existing API or interface suitable for testing purposes, you may need to develop a "shim" to provide the required functionality. A shim can be a software or hardware / software component that sits between the test platform and the system under test, converting data and commands between the two. Apache Thrift can be used to make such a shim.

In situations where a shim is required or the existing interface is not suitable, involve the system's developers in the design and implementation process. Their knowledge of the system's internals can be invaluable in creating an effective interface and ensuring it meets the needs of the test team. 

Ensure that the interfaces and shims you develop or utilize provide the necessary functionality to monitor the status of the system or component, as well as to inject failures and control their behavior. This is essential for comprehensive testing and validation of the system's resilience and robustness.

It's nice to say everything should be well documented, but often, that reality gets left on the table. If you can get access to a tech writer, get one! If not, make use of in-line documentation.