Automated Unit Test

This tutorial will introduce you to BMC AMI DevX Total Test. Total Test allows for rapid creation of COBOL unit tests. Total Test can create Data stubs and Programs stubs allowing you virtualize those components of the application.

  • This tutorial will introduce you to BMC AMI DevX Total Test. Total Test allows for rapid creation of COBOL unit tests. Total Test can create Data/Program stubs allowing you to virtualize all components of the application.
  • BMC AMI DevX Total Test uses BMC AMI DevX Code Debug  to collect program call parameters, I/O from (QSAM, VSAM, Db2, IMS BMP, IMS MPP, CICS) as well as the results data.
  • Test cases can then be run independently using stubs, removing the dependency to data/program accessibility.

Instructions:

  • This guide assumes you have completed the "Getting Started" script.
  • This guide contains many screenshots to provide a visual reference.
  • Every action you must take is in the Info Box.

Setting Up

Total Test Unit Test uses the DevX Code Debug  command 'Generate Test Case' to create the Unit test project. After creating the unit test cases, we'll use Project Explorer to view and run the unit test case.
Open BMC AMI DevX Workbench. Open the Host Explorer perspective. You should have already created a z/OS dataset filter for CWEZxxx.WBSAMP.* Expand the filtered dataset list to locate and highlight CWEZxxx.WBSAMP.JCL

Do This

  • Locate the JCL member CWKTVSKS and right-click to display the context menu. Highlight 'Debug As' and click 'BMC AMI DevX Code Debug  Batch Debug Session'.

 


This will open the Debug Configuration dialog completed with the details extracted from the JCL.

Do This

  • Click Debug. (You may have to enter your userid and password again) if prompted to display the DevX Code Debug  perspective, select 'YES'.

The DevX Code Debug  perspective will populate several views. The main program will encounter a default breakpoint at the procedure division.


Do This

  • In the source code view, right-click to display the context menu and choose Record Test Case.

 You may be prompted to enter your credentials for CES.

Do This

  • Enter your assigned Test Drive ID (i.e. cwezxxx) and password. Click OK.

Do This

  • The Record Test Case dialog box will appear, next to the Project field, click New… to create a new project.

Note: The project field may or may not be populated when this dialog box is first displayed. This Total Test dialog is used to determine what Stubs to create as part of the Test Case.

Do This

  • Enter the project name My_TopazTTProject and select Finish.

The tab 'Unit Test Options' portion of the Record Test Case dialog contains checked boxes that control the generation of stubs.
Program stubs allow a unit test to simulate subprogram. This is especially beneficial when the called program is incomplete and/or unavailable. Data used during the Unit Test creation process is captured and stored with the unit test project. This allows the Unit Test to be run even if the test data has changed or is not available on the target system. The default is set to 1000, as shown here. Unit testing is designed to test with a limited number of input records compared to a full regression test that may use full production size input data.


Do This

  • Verify that all stubs are selected so all relevant stubs are created, Click OK.



Do This

  • Click the Resume icon on the toolbar or press F8 to resume program execution.

Do This

The terminated message will appear within a couple of minutes in the Debug view.

Running the Unit Test

After the program terminates, open the Host Explorer perspective.

Do This

  • Select the Project Explorer tab.



Do This

  • Navigate to and expand the project that was just created and expand the Tests folder.

 
 

Do This

  • Expand the Stubs folder in the project.

Shown is a program stubs for the CWKTDATE module which is called from the main program. Also see two I/O stubs, one for the EMPFILE input file and one for the RPTFILE output file. If DB2, IMS, or CICS were involved in the program, you would see similar stubs for the resources associated with those technologies.


Do This

  • Double-click on the CWKTDATE stub to open in the editor pane (the middle pane.)

One row for each call to CWKTDATE from the main program showing data passed to the sub program via the linkage section is shown.


Do This

  • Double-click on the EMPFILE stub to open in the editor pane (the middle pane.)

One row for each record read from the EMPFILE dataset during the Unit Test creation is shown. The Value column displays and allows you to change the values in the input record for future runs of the Unit Test.


Do This

  • Double-click on the RPTFILE stub to open in the editor pane (the middle pane.)

One row for each record written to the RPTFILE dataset during the Unit Test creation is shown. The Comparison and Expected Value columns are used to validate that the program writes the correct information when the Unit Test is run.
By default, the replay of the test case will use the JCL define to the Repository, the libraries used in the Debug configuration were captured and added to the context file.


Do This

  • Expand the Scenarios folder and double click on the CWKTVSKS.Scenario.testscenario to open it in the editor panel.





Do This

  • The Input Data tab at the top will show the parms passed to the program. Select the Stubs tab.


Do This

This tab allows you to include or exclude which stubs will be used when the Unit Test is run. However, if for example we remove the RMPFILE stub then we need to include the DD statement in the JCL.
If DB2, IMS, or CICS stubs are present, all those stubs must be used.



Do This

  • The Properties tab allows you to document notes and additional information pertaining to the Unit Test Scenario.


Do This



Do This

  • Click on the Run Test Scenario icon on the toolbar. If you get the Logon to Repository see page 7.


This will Open the Testcase Context from the scenario folder.


Do This

  • Select the Unit Test Tab.


Note: that we didn't have to provide the library where the program will be executed from. This was captured from the DevX Code Debug  session from either the Loadlib tab in the Launch Config or your Steplib in your JCL.


Do This

  • Return to the Environment tab, Select TestDrive for Host and Click OK



You will see a progress bar on the lower right of the screen

Reviewing the Unit Test Results

When the Unit Test completes, the report will be displayed in the Editor panel. This report will show a Success rate, number of failures and errors and where the failures occurred. This concludes the Automated Unit testing using Total Test.

Close all of the open tabs in the editor pane.
When the Unit Test completes, the report will be displayed in the Editor panel. This report will show a Success rate, number of failures and errors, and where the failures occurred.
This concludes the Automated Unit testing using BMC AMI DevX Total Test.

Restarting This Script

At any point should you need to restart this Test Drive script, follow the instructions below: You can reuse the same Launch configuration to start the debug session. For the Total Test Project use the same project name and add a '1' to the name to make it unique.

Next Steps

For more information about "Mainstreaming the Mainframe" visit our Mainframe DevOps site.

Was this page helpful? Yes No Submitting... Thank you

Comments