1 CR 0413: Static Test Configurations

2 Requirements Allow to handle test configurations that can be used by several test cases. Support transfer of information between test cases on component level. All other technical requirements in the CR are more or less non-critical or come automatically with the resolution.

3 Approaches1(2) Simple approach: Make MTC to an alive component and allow to transfer alive components over test cases. Problems: Configuration is somehow hidden in test case definition. Configuration information is difficult to transfer.

4 Approaches2(2) CR approach: Introduce a new configuration type. The instantiation of this new type is the test configuration. The configuration include a declaration part and functions to instantiate (constructor) and destroy (destructor) the configuration. Test cases refer to this configuration in their definition and are executed on this configuration.

5 DeclarationsConstructor Destructor Other Functions Example according to CR 1(x) type configuration conf_type runs on comp_type1 system comp_type2 { var integer static_variable; var rec_of_ptc_components ptc_components; function constructor(){ static_variable := 0; ptc_components[ 0 ] := ptc_base_component.create; ptc_components[ 1 ] := ptc_base_component.create; connect(ptc_components[ 0 ]:PORT, ptc_components[ 1 ]:PORT); } function destructor(){ disconnect(ptc_components[ 0 ]:PORT, ptc_components[ 1 ]:PORT); all component.done; ptc_components[ 0 ].kill; ptc_components[ 1 ].kill; } function increase_by(integer number) { Static_variable := static_variable + number; } } // end of the configuration declaration

6 Behaviour of „execute“ becomes context sensitive! - Implicit set-up on execution of TC1 - Implicit destruction after execution of TC2 Control Part Test Case definitions Example according to CR 2(x) testcase TC1() configuration conf_type { ptc_components[ 0 ].start(receiving()); increase_by(1); if( static_variable == 1 ) { setverdict(pass); } else { setverdict(fail); } } testcase TC2() configuration conf_type { ptc_components[ 1 ].start(sending()); increase_by(1); if( static_variable <= 2 ) { setverdict(pass); } else { setverdict(fail); } } control{ execute(TC1()); execute(TC2()); }

7 Example according to CR 3(x) control{ execute(TC1()); execute(TC2()); } Problems with the execute Behaviour of execute becomes context sensitive Configuration for TC1 is implicitly created if it does not exist. If TC2 has the same configuration as TC1 the same configuration will be used otherwise the configuration of TC1 will be destroyed and a new configuration will be constructed. The configuration exists implicitly. It would be nicer to handle it explicitly possibly even modify it.

8 Special semantics can access configuration declarations Example according to CR 4(x) type configuration conf_type runs on comp_type1 system comp_type2 { var integer static_variable; var rec_of_ptc_components ptc_components; function constructor(){ static_variable := 0; ptc_components[ 0 ] := ptc_base_component.create; ptc_components[ 1 ] := ptc_base_component.create; connect(ptc_components[ 0 ]:PORT, ptc_components[ 1 ]:PORT); } function destructor(){ disconnect(ptc_components[ 0 ]:PORT, ptc_components[ 1 ]:PORT); all component.done; ptc_components[ 0 ].kill; ptc_components[ 1 ].kill; } function increase_by(integer number) { Static_variable := static_variable + number; } } // end of the configuration declaration

9 Example according to CR 5(x) My interpretation of the CR concering configuration type declarations: Configuration type declarations are a special type of MTC declarations that can only be accessed/changed by MTC. They keep their values between different test cases. Values of component type variables (including MTC) will be reinitialized when the next test case is executed. Suprisingly, the message queues shall keep their contents! The reinitialization of test component variables with the exception of queues is somehow inconsistent with the semantics of starting alive components (all variables are static)! I already know the next CRs on this issue: We also need static variables on PTC level. Timers need also to be kept.

10 Further problems Copied from CR: Those and only those PTCs would be static, which are created inside the functions of the configuration (i.e. either at configuration creation or by a user function). For these PTCs only the running / done / alive / killed operations can be used from outside the configuration’s functions (these don’t change the PTC’s state). For static ports only in the configuration’s functions would it be possible to call connect, disconnect, map, unmap. The behaviour of all mentioned functions/operations will become context sensitive!

11 Proposal to resolve the issues

12 Configuration Type Usage Configuration becomes an „object“ that has to be created explicitly, has to be destroyed explicitly and has to be referenced whenever it is used. Schematical example (Syntax requires discussion): var configuration MyConfig := create.MyConfigType(MyPar); MyVerdict := start.MyTestCase() on MyConfig; kill.MyConfig; Possible further operations on configurations: modify, reset

13 Configuration Type Definition Configuration type definition only includes a constructor and if required a destructor. The constructor is basically a set of configuration operations executed by the MTC of the configuration. This means it creates alive components and makes the connections and mappings. All alive components and their ports are static ports. The MTC becomes basically also an alive component. Possible extensions Allowing to run initialization functions on the alive components. Allowing to create non-alive components during test set-up in order to configure the SUT.

14 Component variables As today for alive components, for all alive components and MTC all variables, timers, etc. are static, i.e. keep their values when switching the test case. Possible extension: reset function for components Alternative solution: Introduction of static variables, but to harmonize this with the existing alive components this would require a non-backwards compatible change in the standard.

15 Starting a test case on a configuration MyVerdict := start.MyTestCase() on MyConfig; The body of the test case is executed on the MTC of MyConfig. Possible configuration information can be stored in the component variables of the MTC type. The MTC starts the behaviour on all PTCs.

16 Note We could even allow to change configurations in between test cases. We have all the operations from the alive components.