Mechanism for making integration tests parametric w.r.t. components and environment

We need to make sure that integration tests (even those used in PI integration testing) are agnostic w.r.t. the specific components that are deployed in their SUT, as well as the test environment.

For example, for Solution goal 1 for PI18, the relevant tests refer to an SUT that is specific for <goal1, PI18>. Once such a test is implemented and we decide that it delivers what it should, then we might promote it to the appropriate regression testing suite. But in that new context, what is the actual SUT that the test should refer to? For example, that test will be routinely executed day in and day out during future PIs, when the context <goal1, PI18> is not relevant any more, just like the SUT it refers to. In a sense, SUTs morph as PIs evolve and we need to make sure that there is a precise and explicit way in which we associate a test to its relevant SUT.

One such mechanism could be a clever parameterization of tests such that:

• they identify the components they need (eg. by a list of generic names such as "TMC, CSP.LMC, LOW CBF, SDP"), but 
• they are agnostic of what are the actual concrete components that constitute the SUT, and
• such concrete realisations are injected by the deployment/test execution machinery (some fixture) based on information derived from the execution context specified in some field of a test plan/set or via environmental variables.