COMPUWARE TEST DRIVE

Automated Unit Testing (3/6/19)

2

Table of Contents

GETTING STARTED _________________________________________________________________ 3

GETTING TO KNOW TOPAZ FOR TOTAL TEST ____________________________________________ 4

SETTING UP ____________________________________________________________________________ 4

CREATING A UNIT TEST __________________________________________________________________ 9

SETTING UP AND RUNNING THE UNIT TEST _________________________________________________ 18

REVIEWING THE UNIT TEST RESULTS_______________________________________________________ 31

GENERATE TEST CASE FOR SUBPROGRAM TEST ______________________________________________ 32

NEXT STEPS _____________________________________________________________________ 44

3

GETTING STARTED

In this tutorial, you will create reusable test scenarios and run them independently with data stubs, regardless of data accessibility.

Instructions:

• This guide contains many screenshots to provide a visual reference

• Every action you must take is in BOLD

• Please note each place that you must enter your own specific ID or number

• You must complete each step before proceeding to the next to successfully follow the

test drive script.

The Compuware Test Drive Experience requires that the user must have

completed the Building Your Environment exercise before starting any tutorial script.

http://resources.compuware.com/hubfs/Test%20Drive/Building_Environment_with_Host_and_JES_Explorers_TW_Test_Drive.pdf If, at any point during your experience, your host connection times out, you may need to log back in to the Test Drive host connection.

4

GETTING TO KNOW TOPAZ FOR TOTAL TEST

SETTING UP

Topaz for Total Test allows you to generate a program unit test. First, we’ll use Host Explorer to copy and modify program execution JCL. Then we’ll use the Xpediter debugger to create a debug configuration that runs a program and generates its unit test. After setting up the unit tests, we’ll use Project Explorer to run them.

• Open Topaz Workbench.

• Open the Host Explorer perspective.

• Set up a z/OS dataset filter for cwez000.topaz, as shown.

• Expand the filtered dataset list to locate and highlight CWEZ000.TOPAZ.XPED.CNTL, then

right-click to display the context menu.

5

• In the context menu, choose Copy To…

• In the Copy to Host dialog box, highlight the Source/Target dataset names, and click Rename…

6

• In the Rename Target Dataset dialog box, change the name to CWEZnnn.TOPAZTT.XPED.CNTL, where

CWEZnnn is the TSO userid assigned to you for this workshop.

• Click OK when complete.

• When the Rename Target Dataset dialog box closes, click Copy.

7

• Look for the “Success” message in the Status column and click Close.

• In the Host Explorer directory, create a z/OS dataset filter for the new dataset name created.

8

• Expand the dataset list and then the member list for the dataset just created

(CWEZnnn.TOPAZTT.XPED.CNTL).

• Double-click on member CWKTVSKS to open for editing.

Note: Your dataset list may differ from the one shown.

• When the edit window opens, change the CWEZNNNX job name to your userid + X similar to the one shown.

Filter on your dataset

Your userid + X

9

• Close the edit window by clicking the X in the top right corner of the tab.

• Click Yes in the confirmation dialog box to save the changes.

CREATING A UNIT TEST

• Open the Xpediter perspective by clicking on Compuware on the tool bar and selecting Xpediter from the drop-down menu

10

• Open the Run dropdown from the top navigation, and choose Debug Configurations…

Note: You may have to scroll down in the dropdown to locate Debug Configurations.

• Single-click on Xpediter Batch Debug Session to highlight and create that type then Click on the left-most icon on the toolbar to create a new configuration

11

• Replace the default new configuration name with one of your choosing, then enter PDS and member name of the JCL [youruserid.TOPAZTT.XPED.CNTL(CWKTVSKS)].

• Click Autofill to populate the jobname, step and program information.

Application JCL

Click Autofill

ck Autofill

12

• Select the Breakpoints tab and choose Load the main module only option to eliminate unneeded breakpoints.

• Click on the DDIO tab and then click on the Add… button.

13

• Add the dataset CWEZ000.TOPAZ.TTT.SHRDIR and click OK

14

• Click Debug. (You may have to enter your userid and password again) Xpediter will populate numerous views as the program runs. The main program will encounter a breakpoint at the procedure division.

• In the source code view, right-click to display the context menu and choose Generate Unit Test… from the context menu.

15

• In the Generate Unit Test dialog box, 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.

• Enter a project name of your choosing and select Finish.

16

• The lower portion of the Generate Unit Test dialog box contains check boxes that control the generation of stubs. Verify that all stubs options are selected so all relevant stubs are created, then click OK

Program stubs allow a unit test to simulate subprogram/subroutine calls. This is especially beneficial when the called code is incomplete and/or unavailable.

I/O stubs allow a unit test to bypass reads and writes. 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 maximum number of records should be set to a relatively low number such a 100, 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.

17

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

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

18

SETTING UP AND RUNNING THE UNIT TEST

• After the program terminates, open the Host Explorer perspective.

19

• Select the Project Explorer tab. Navigate to and expand the project that was just created and expand the Unit Test folder.

20

• Expand the JCL folder and double-click Runner.jcl in the JCL folder to open the jcl in the editor panel.

21

• The RUNNER JCL requires change to the job card as well as two datasets to the STEPLIB concatenation.

• We’ll copy this JCL, return to Host Explorer and expand the dataset list and then member list for the dataset:

(CWEZnnn.TOPAZTT.XPED.CNTL(RUNNER))

• Select member (RUNNER), right click and Copy. Return to Project Explorer and Paste the Runner JCL. Say “yes to all’

when you perform the Paste.

• When the edit window opens, change the CWEZNNNX job name to your userid + X similar to the one shown.

22

• Close the tab by clicking on the X and select Yes to save your changes.

• Click on the Stubs folder in the project. You will see a program stub for the CWKTDATE module which is called from the main program. You will also see two I/O stubs, one for the EMPFILE input file and one for the RPTFILE output file. If DB2, IMS or CICS where involved in the program, you would see similar stubs for the resources associated with those technologies.

T

Click on the X to close

23

• Double-click on the CWKTDATE stub to open the stub in the editor pane (the middle pane). You will see one row for each call of to CWXTDATE from the main program showing that data passed to and from the sub program via the linkage section.

24

• Double-click on the EMPFILE stub to open the stub in the editor pane (the middle pane). You will see one row for each record read from the EMPFILE dataset during the Unit Test creation. The Value column displays and allows you to change the values in the input record for future runs of the Unit Test.

• Double-click on the RPTFILE stub to open the stub in the editor pane (the middle pane). You will see one row for each record written to the RPTFILE dataset during the Unit Test creation. The Comparison and Expected Value columns are used to validate that the program writes the correct information when the Unit Test is run.

25

26

• Expand the Scenarios folder and double click on the CWKTVSKS scenario to open it in the editor pane.

• Double click on the CWKTVSKS scenario to open it in the editor window.

• The Input Data tab at the bottom will show the parms passed to the program.

•

27

• The Stubs tab allows you to select or exclude which stubs will be used when the Unit Test is run. If DB2,

IMS or CICS stubs are present, all of those stubs must be used.

28

• The Information tab allows you to document notes and additional information pertaining to the Unit

TestScenario.

29

• Click on the Run Test Scenario icon on the toolbar.

30

• In the Test Run dialog box that appears, Select Test Drive in the Host Connection pull down menu, Select Runner.jcl in the JCL template section and verify the Use stubs and Delete temporary files boxes are checked. Then click OK

31

• A status box similar to the one below will appear which will show the progress of the Unit Test execution.

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 Topaz for Total Test.

32

GENERATE TEST CASE FOR SUBPROGRAM TEST

Topaz for Total Test allows you to generate a unit test for testing your subprograms. First, we’ll use the Xpediter debug configuration used for creating our Test Case for the CWKTVSKS program. After setting up the unit tests, we’ll use Project Explorer to run them.

• Open the Run dropdown from the top navigation, and choose Debug Configurations…

Note: You may have to scroll down in the dropdown to locate Debug Configurations.

33

• Select ‘MY_TopazTT_Debug_Config’ or the name of the debug configuration you defined for Unit Test creation in previous step. We’ll use the same Debug configuration as we used for our Unit Test Case creation. You will still need to invoke the full application to generate the Test Case for the Subroutine.

Click Debug. (You may have to enter your userid and password again). Xpediter will populate numerous views as the program runs. The main program will encounter a breakpoint at the procedure division.

• Once in the Xpediter Perspective enter the Main program CWKTVSKS in the DDIO view. This will list any CSECTs

(subprograms). If this a dynamically called module you will put the CSECT name instead.

Use the same Debug Config

Relaunch Debug Config

34

• Next, right-click the CWXTDATE program in the DDIO view, select ‘Set Initial Breakpoint’ on the subprogram, this will cause Xpediter to pause once the subprogram is called during execution.

Specify the main program

35

• You will now see both the Main and subprograms source listings.

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

36

• Notice that Xpediter is paused at the start of the Subprogram

• In the source code view, right-click to display the context menu and choose Generate Unit Test… from the context

menu.

37

• Best Practices suggest that a new project be created for the new Test case.

• The lower portion of the Generate Unit Test dialog box contains check boxes that control the generation of stubs. Verify that all stubs options are selected so all relevant stubs are created, then click OK

If your Subprogram performs calls to additional subprograms then Program stubs will be created.

I/O stubs allow a unit test to bypass reads and writes. 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 of the test data has changed or is not available on the target system.

The maximum number of records should be set to a relatively low number such a 100, as shown here.

38

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

• Before clicking the Resume icon on the toolbar or press F8 to resume program execution, uncheck the CWXTDATE breakpoint in the Breakpoints view, this subroutine gets called several times.

• Click Resume or F8 (if not already done so)

• Switch to “Host Explorer” perspective and click on “Project Explorer” view

Uncheck CWXTDATE breakpoint

39

• Since the Load library is the same as the previous test case created you can copy/paste the Runner JCL from one to project to another.

40

• Say “yes to all’ when you perform the Paste.

41

• Expand the Scenarios folder and double click on the CWKTDATE scenario to open it in the editor pane.

• The Input Data tab at the bottom will show the parms passed to the program.

42

• The Stubs tab doesn’t show any stubs because this program didn’t call any additional programs.

• The Assertion tab provides flexibility for data values used in the unit test. The Comparison operator and/or Value may be changed so that data values other than those captured in the I/O stubs may be used.

43

• Click on the Run Test Scenario icon on the toolbar.

• In the Test Run dialog box that appears, Select Test Drive in the Host Connection pull down menu, Select Runner.jcl in the JCL template section and verify the Use stubs and Delete temporary files boxes are checked. Then click OK

44

• A Status box similar to the one below will appear which shows the progress of the Test Case.

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 Subprogram testing using Topaz for Total Test. You can close the report by clicking on the x in editor tab.

NEXT STEPS

Click on the link below to return to the Compuware Test Drive main page and choose your next road trip!

COMPUWARE TEST DRIVE