Helper Functions and Port Relay Operations
Helper Functions
Test architectures offer appropriate test components for the association ends and ports of the SUT. These test components can be edited by the user without affecting the original model. The user can add functionality to existing test components or add additional test components, according to the needs of testing and test case generation. In particular, test components can be equipped with so called helper functions. Helper functions can be designed to trigger certain behavior of the SUT or to invoke operations in a particular sequence or to send a series of events to the SUT in a user defined order e.t.c.
User defined helper functions can enhance test case generation if e.g. ATG can't generate particular sequences of triggers, or if an operation can't be invoked by ATG directly due to unsupported argument types such as pointers, references, structures, or other user defined types. For example, a helper function can be created by the user, aimed at invoking a SUT function Operation_x(struct X* arg) with pointer to a structure X argument (struct X* arg). Let struct X consist of two integers and a boolean element:
struct X { int x; int y; bool b; };
Then the helper function could be designed with two integer and a boolean argument. In the implementation of the helper function, a variable varX of type struct X could be declared and its elements are assigned the values of the helper function's arguments. Finally, the SUT function could be invoked with the address of varX (assumed that test component TC_X has an association end itsSUT pointing to the class of the SUT):
void TC_X::drive_SUT_op(int ax, int ay, bool ab) { struct X varX; varX.x=ax; varX.y=ay; varX.b=ab; itsSUT->Operation_x(&varX); }
While Operation_X(struct X* arg) can't be invoked by ATG directly for test case generation, TC_X::drive_SUT_op(int ax, int ay, bool ab) can.
The ATG Tutorial gives an example of using helper functions.
Port relay operations
Port relay operations are a special form of auto generated helper functions.
Depending on property 'AutomaticTestGenerator.Settings.StimulationInterfaceMode' of the referenced code generation configuration, ATG equips the test components introduced for ports of the SUT with helper functions. These helper functions allow invocation of operations in the SUT and sending events to the SUT via the port connections in the test architecture.
For each event reception and operation in the provided contract of a SUT's port the corresponding test component is equipped with a port relay operation with appropriate arguments that can be invoked by ATG in order to call the SUT operation or to send the respective event to the SUT via the link between test component port and SUT port.
Port relay operations can be edited by the user, e.g. in order to provide values for complex argument types in operations or event receptions of the SUT. For example, ATG can not provide appropriate values for pointer to structure arguments of SUT operations. Here, the user can enhance the ATG input interface with a modification of the respective port relay operation: A port relay operation for the respective operation could be provided with scalar type arguments for the members of the structure. In the body of the port relay operation, the structure could be allocated, the arguments could be assigned to the fields of the structure and the pointer to the structure could be used as argument to call the SUT's operation. This way, also complex arguments can be supported in input interfaces in ATG.
Stereotype <<RelayOperation>>
The testing profile offers a stereotype <<RelayOperation>> applicable on operations. This stereotype determines which operations of test components shall be used in the port based predefinition mode in the ATG input interface selection dialog. Port relay operations are automatically stereotyped accordingly by ATG, but also user defined helper functions can be stereotyped as <<RelayOperation>>. These operations will then automatically be regarded when defining the input interface according to test context (port based)