Associated test cases

Associated Test Cases are used in collaboration with the user’s application. They contain a collection of load module entry points, named by a specific format, that become available as exit points by the runner. By using these exit points, a user may get access to the original calls being made to and from the user application program, allowing the code at the exit point to inspect, modify or even issue asserts that can be set to stop playback execution. This is done without requiring any changes to the original user application, opening the door to allow the user to code “what if” scenarios that can help with altering code flow or testing alternate conditions.

Any number of Associated Test Cases can be made available to the replaying of an application. The configuration TESTCASE command allows a user to define a list of comma-separated patterns to be used for searching a test case load library. Any number of TESTCASE commands can also be used in the configuration file. For each of these commands, the list of names to pattern match is generated. Then for each test case load library module that matches the name, it is dynamically loaded and inspected for exit points. These valid exit points are remembered and invoked during playback execution. This process makes the usage of test cases and exit points dynamic. There is no registration, nor any relinking that needs to be performed. The process simply finds all the exit points dynamically, triggered by a simple TESTCASE XML-style command.

It is important to understand that when access to an exit point is provided, the user may alter an argument on the intercepted call. Normally, only output arguments would be modified as these output arguments are what are returned to the calling program. It would generally be ineffective to modify the input argument. Depending on where the input argument is stored in the load module, attempting to perform an input argument modification could result in a protection exception abend during execution. It is also important to understand that attempting to move more data into the argument than was originally defined for the area in the user application program would likely cause on overlay of program memory and cause unintended consequences. Similarly, attempting to extend the CICS communication area past the end of the size that was provided could cause a protection exception abend. This would be true of any control block passed during the exit point.

Associated Test Cases are designed to work more closely with a developer. Associated Test Cases allow a user to:

• acquire access to CICS, Db2, IMS or IBM MQ arguments on both sides of the call
• acquire access to intercepted programs arguments on both sides of the program call
• define individual tests that can target a single program, if desired
• make verification test suites that test out a variety of situations
• alter the results of a call by changing its arguments
• test argument data on calls and issue messages or asserts

By using Associated Test Cases, you can perform a more thorough set of tests on a program or transaction or allow a user to see the effects of running the program with a changed value being return from a specific intercepted call.