Testing mainframe applications with Total Test

This topic provides detailed information about Source Support with Total Test. For more information, see BMC AMI DevX Total Test documentation.

Total Test can test a mainframe program in two ways:

  • Virtualized (unit testing): Total Test virtualizes or stubs out all subprogram calls, data accessed, and API calls, and it tests the program in complete isolation from external dependencies.
  • Non-virtualized (functional and integration testing): Total Test runs the test in a real environment with real subprograms and data.

Virtualized Testing test case recording

To record a test case, Total Test requires the source listing and uses it to create the stubs that record the data. When you compile a COBOL program with optimization, Total Test also requires the TEST and LIST options to record successfully. For more information about optimization, see Working-with-the-compiler-optimizer-and-Code-Debug.

Related topics

Source-Support-best-practices

Toolkit-for-adapting-existing-implementations

Virtualized Testing test execution

For virtualized testing (unit testing), when running a test, Total Test uses the source listing to enable virtualized testing. It is a requirement for CICS, Db2 SQL, IMS CBLTDLI, and statically linked subprogram calls. Other types of stubs do not require the source listing.

For COBOL (starting with release 5), we highly recommend Embedded Source Support (ESS). Where this is not available, we recommend that you specify the DDIO's user IDRDATA to aid Test Runner in locating and opening the DDIO source listing of the program it is testing. Finally, if you cannot use the DDIO'S user IDRDATA, then the Test Runner will, by default, use the DDIO shared directory used by Code Debug when you recorded the test case. An example is if a conflict exists with another product that also updates user IDRDATA.

In some instances, Total Test might require you to modify TTTRUNNR.jcl (the JCL used for running the test scenario) to include the SLSF00n DD, where n is a number from 1 through 8. You can specify multiple SLSF00n DDs may be specified. An example follows:

//SLSF001 DD DISP=SHR,DSN=USER.TEST.PAYROLL.SSD
//SLSF002 DD DISP=SHR,DSN=USER.TEST2.PAYROLL.SSD
//SLSF003 DD DISP=SHR,DSN=USER.PROD.PAYROLL.SSD

Total Test might require SLSF00n DDs when not using Embedded Source Support in the following scenarios:

  • You moved the DDIO source listing from the DDIO shared directory used by Code Debug when you recorded the test case or specified by DDIO's user IDRDATA read during the test run.
  • You recompiled the program that Total Test is testing after Code Debug used it to record the test case, and the compile procedure specified a different DDIO shared directory to store the listing.

Virtualized Testing test running and Code Coverage

When you run a test scenario using Total Test, it can collect Code Coverage data. To pass Code Coverage data to SonarSource, it requires pre-processed listings, as described in Implementing-Source-Support-Best-Practices. Pre-processed listings include additional information that is needed when using SonarSource.

Important

Regarding CA Endevor listing data sets (ELIBs) you cannot use a BMC AMI preprocessor enhanced listing for passing code coverage data to SonarSource if you store it in an ELIB rather than a BMC AMI source listing data set.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*