Unit testing versus integration testing

When you start a test session, you can specify the subroutine program name on the test screen to do unit testing instead of executing the main program and calling the subroutine. Whether you choose to do unit testing or integration testing, you need only reassemble your selected program and create the source listing members. For programs that do not have source listing members, you can use the Code Debug TSO PSEUDOSOURCE command or the AT command. For additional command information, see the Command-and-syntax-reference. For additional testing information, see the Creating Pseudo-Assembler Source and Debugging a Sourceless Program. You could also use the Memory screen (MEMORY command) or the general register display window (GPREGS command). With the MEMORY command and AT command methods, however, you are not able to place breakpoints or interact at the source level.

When unit testing a subroutine, specify the program name on the test screen. If the program is a member of a static composite load module, specify the load module name in addition to the program name. This notifies Code Debug TSO that the program name differs from the load module name (see the following figure). The PARM String field on the screen is used to pass run-time parameters in the execution JCL to your program. Do not use it to specify parameters that are passed from the driver program to the subroutine.

Stand-alone subroutine testing of a batch IMS/DB program is not supported if the subroutine issues DLI calls.

Unit Testing Subroutine TRITSTA of Load Module TRIMAINA

Once the source display becomes available, you must establish addressability to the program and initialize data areas as if the subroutine had been called from the driver program. To initialize data areas, use the MOVE command or type over data values that are displayed by the PEEK, KEEP, VERIFY, or MEMORY command. To reassign the DSECT address, use the USING or DROP command. To allocate virtual storage, use the GETMAIN command. See the Inspecting Program Data for more information on these commands.

If you wish to rerun the same test repeatedly, you can facilitate the initialization process by storing the stream of Code Debug TSO commands in an INCLUDE script and re-executing the script at the beginning of each test session.

When integration testing a subroutine that is called by a main program, specify the main program name instead of the subroutine program name on the test screen. When you press Enter, the main program source is displayed if there is a source listing member for it; otherwise, the session log is displayed. To pause in the subroutine, choose one of the following:

1. Display the source of the called program using the SOURCE command and set breakpoints.
2. Enter INTERCEPT on the primary command line. This places breakpoints at the beginning and end of the specified program and displays the source.
3. Enter a qualified breakpoint from the main program. A qualified breakpoint is a form of breakpoint syntax that is delimited by a target module name. For example, to set a qualified breakpoint at a specific offset in the module TRITSTA from the main program TRIMAINA, enter the following from the TRIMAINA source screen.
   BEFORE TRITSTA:+14
   The command BEFORE TRITSTA: places a breakpoint at the beginning of module TRITSTA. BEFORE TRITSTA:+14 places a breakpoint at offset X’14’ in module TRITSTA. When you execute your program by pressing PF12 (GO), the program stops at the specified breakpoint and displays the source representation. See Debugging Interactively for more information on breakpoints. See the Command-and-syntax-reference for information about qualification rules for Code Debug TSO commands.
   If you are placing a breakpoint in a member of a composite load module called by a driver program, you first load the composite load module into memory and then attempt to set breakpoints or display the source. The Code Debug TSO commands INTERCEPT and SOURCE are used to load programs into memory.