Using Functional Test with Code Coverage

Code Coverage collection for CICS consists of defining the test criteria, beginning the Code Coverage data collection, executing the CICS transactions, and halting the collection.

Test Data Collection

1. From an active Code Debug CICS session, click on the Add Test Definition icon in the CICS Code Coverage view to add a Test Definition:
   
2. In the Add a Test Definition dialog, enter a System name and Test ID.
3. Press Next.
4. In the Test Definition Specification dialog, first specify the user ID:
5. Click Add... to display the Add User ID dialog.
6. Select the desired Entry Type, either Include or Exclude.
7. Enter a TSO User ID or ******* to allow all user ids in the User ID field.
8. Click OK.
9. Click Add... in the Masks section to display the Add Mask dialog.
10. Select the desired Entry Type, either Include or Exclude.
11. In the Transaction field, specify a transaction code. Use **** to allow any transaction.
12. In the Program field, specify the program name to be covered in your test.
13. In the CSECT field, specify the CSECT name to be covered in your test.
14. Click OK.
    After validating your entries, your test definition shows as Available in the CICS Code Coverage view.
15. In the Code Coverage view, right-click the test definition and select Start Collection, then Start Code Coverage.
    
16. Now execute your Non-virtualized Test test.
17. After the Non-virtualized Test test has finished, right-click the Test entry and select Extract, then Extract Entry.
    This writes the coverage data to the repository. Reports are created from there.
    

Create CICS Code Coverage Reports

1. Switch to the Code Coverage perspective.
2. In the Code Coverage view, do one of the following:
   1. Click the Create a New a New Report Request icon.

   2. Right-click the Report Requests folder and select New.

      The Code Coverage Report Request dialog box appears.
      

3. In the Report request name field, enter a name for the report.
4. From the Host list, select a host or configure a host.
5. From the Repository list, select or browse to the repository to be used when creating Code Coverage reports.
6. From the Summary level list, select how data in the repository should be summarized:
   • Select Systems to see summary information about all systems contained in the repository. Results are merged for headers with the same system name, load module, and program name, regardless of test ID or user ID.
   • Select Test IDs to see the effectiveness of individual tests within a system and see how completely each system has been tested by all tests. The Test IDs level gives the system name, test ID, and program of all programs in the repository. Load module and user ID are ignored. Each system can have multiple test IDs, and each test ID can have multiple programs. Programs with the same test ID and system name are merged.
   • Select Users to quickly see the amount of testing done by each user. It gives the system name, user ID, and program for all programs in the repositories. Load module and test ID are ignored. Programs with the same user ID and system name are merged.
   • Select Load Modules to display code coverage results for all load modules in the repositories. Code coverage results are merged for all programs in load modules with the same name—regardless of the system, test ID, or user ID. This is helpful when the same load module is used by several systems and the user wants to know the code coverage results regardless of the system that executed it.
   • Select Programs to display code coverage results for all programs contained in the repositories. It merges code coverage results for runs of a program that have the same compile data and time, regardless of the systems, load modules, test IDs, and user IDs from which they were executed.
7. Select the Criteria tab, then select one of the following buttons:
   • Select Specify names and enter any system, test ID, user ID, load module, and program names to retrieve only the data that matches the criteria. It is not necessary to complete all of the fields. Wildcards may be used as a suffix. Leaving all fields blank retrieves all data.
   • Select Specify a list, choose a type from the Type list, then select items from the list showing all items of the selected type that are in the chosen repository.
8. Optionally, select the Filters tab, then do one of the following:
   • To apply existing filters to the report, select the check boxes for the applicable filter(s).
   • Create new filters and apply them to the report
9. Optionally, select the Options tab, then select the Combine altered debug sessions with unaltered sessions check box to merge debug and non-debug results, or clear it to leave debug and non-debug results as separate entries in the Code Coverage report.
10. Click the Run button.

View the Code Coverage Report

1. In the Report Requests folder, double-click the desired report. The results appear in the Report View.

   The report view displays the summary Code Coverage results. The default columns in the report view display the following code coverage data:

   • Name – The systems and, depending on the summary level selected on the Code Coverage Report Criteria page, the test IDs, user IDs, load modules, or programs contained in the repository. For programs, this column lists the compile date and time and, if applicable, a debug indicator and an optimized indicator.
   • Risk – The estimated risk for the systems, load modules, and programs.Any risk greater than 800 appears in red.
   • Critical verb % – If a critical filter was specified, the percentage of critical verbs executed.
   • Verb % – The percentage of verbs that were executed.
   • Critical branch % – If a critical filter was specified, the percentage of critical branches executed in the program.
   • Branch % – The percentage of branches that were executed.

   For more detailed information on the Report View, see the BMC-AMI-DevX-Workbench-Code-Coverage-Eclipse-User-Guide. 

2. Right-click the program to view.

3. Select View Annotated Listing.

   

4. The Annotated Listing appears and the Annotations view populates with detailed summary information about the source listing.
   
5. Do the following:
   Review the highlighting in the Annotated Listing determine the extent to which code was executed. By default, the following colors are used:
   • Green indicates executed verbs.
   • Yellow indicates partially executed branches.
   • Red indicates unexecuted verbs.
   • Gray indicates an optimized line.
6. Review the Annotations View.

The Annotations view shows a summary of all annotations in the Annotated Listing. From this view, you can go directly to any line in the Annotated Listing, such as an unexecuted line. By default, the Annotations view is grouped by execution status.

For more information on the Annotations Listing and Annotations View, see the BMC-AMI-DevX-Workbench-Code-Coverage-Eclipse-User-Guide.