COMPUWARE TEST DRIVE TOPAZ WORKBENCH WORKSHOP. Automated Unit Testing

Size: px

Start display at page:

Download "COMPUWARE TEST DRIVE TOPAZ WORKBENCH WORKSHOP. Automated Unit Testing"

Edmund Holmes
5 years ago
Views:

1 COMPUWARE TEST DRIVE TOPAZ WORKBENCH WORKSHOP Automated Unit Testing

2 In this tutorial, you will create reusable test scenarios and run them independently with data stubs, regardless of data accessibility. TABLE OF CONTENTS GETTING TO KNOW TOPAZ FOR TOTAL TEST... 2 GENERATING A UNIT TEST...25 APPENDIX A: DATASET FILTERS...55 APPENDIX B: OPENING PERSPECTIVES APPENDIX C: RESIZING VIEW PANES...59 NEXT STEPS...61 GETTING TO KNOW TOPAZ FOR TOTAL TEST 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. 1. Open Topaz Workbench. 2. Open the Host Explorer perspective. 3. Set up a z/os dataset filter for cwez000.topaz, as shown. NOTE: To learn about dataset filtering, see Appendix A. 4. Expand the filtered dataset list to locate and highlight CWEZ000.TOPAZ.XPED.CNTL, then right-click to display the context menu. 2

3 5. In the context menu, choose Copy To 6. In the Copy to Host dialog box, highlight the Source/Target dataset names, and click Rename 3

4 7. 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. 8. Click OK when complete. 9. When the Rename Target Dataset dialog box closes, click Copy. 4

5 10. Look for the Success message in the Status column, and click Close. 11. In the Host Explorer directory, create a z/os dataset filter for your userid. 5

12. Expand the dataset list and then the member list for the dataset just created (CWEZnnn.TOPAZTT.XPED.CNTL). Note: To learn about dataset filtering, see Appendix A. 13.

6 12. Expand the dataset list and then the member list for the dataset just created (CWEZnnn.TOPAZTT.XPED.CNTL). Note: To learn about dataset filtering, see Appendix A. 13. Double-click on member CWKTVSKS to open for editing. Note: Your dataset list may differ from the one shown. 14. When the edit window opens, change the CWEZNNNX job name to your userid + X, similar to the one shown. 6

7 15. Close the edit window by clicking the X in the top right corner of the tab. 16. Save the changes in the confirmation dialog box. 17. Open the Xpediter perspective. Note: To learn about opening perspectives, see Appendix B. 7

8 18. 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. 19. Single-click on Xpediter Batch Debug Session to highlight and create that type. 20. Click on the left-most icon on the toolbar to create a new configuration. 8

member name: [youruserid.topaztt.xped.cntl(cwktvsks)]. 22.

9 21. Replace the default new configuration name with one of your choosing, then enter the job run JCL, including the member name: [youruserid.topaztt.xped.cntl(cwktvsks)]. 22. Click Autofill to populate the jobname, step and program information. 9

Scroll to the right in the top navigation to select the

10 23. Select the Breakpoints tab, and choose Load the main module only option to eliminate unneeded breakpoints. 24. Scroll to the right in the top navigation to select the DDIO tab. 25. Add the dataset CWEZ000.TOPAZ.TTT.SHRDIR. 10

11 26. Click Debug. Xpediter will populate numerous views as the program runs. The main program will encounter a breakpoint at the procedure division. 27. Right-click to display the context menu. 28. Choose Generate Unit Test from the context menu. 11

12 29. In the Generate Unit Test dialog box, click New Note: The project field may or may not be populated when this dialog box is first displayed. 30. Enter a project name of your choosing, and select Finish. 12

13 The lower portion of the Generate Unit Test dialog box contains Stub options, where all of the boxes should be checked, as shown. 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. Actual data used during the Xpediter program run is captured and stored with the unit test package. The convenience here is that necessary files may be difficult to reproduce or unavailable in the testing environment The maximum number of records should be set to 100, as shown here. This number should never be large, so it is consistent with the purpose of unit testing. 31. When done, click on OK. With the unit testing information collection specified, the paused program may be restarted. 13

14 32. Click the Resume icon on the toolbar or press F8. The terminated message will appear within a couple of minutes in the Debug view. 33. After the program terminates, reopen the Host Explorer perspective. 14

15 34. Select the Project Explorer tab. 35. Navigate to and expand the Unit Test project that was just created. 36. Double-click Runner.jcl in the JCL folder. 15

16 As noted in the JCL comments, you must add a job card as well as two steplib cards: main and concatenated. For the job card: //CWEZnnnT JOB (TESTDRIVE),CLASS=Q,MSGCLASS=R,REGION=0M (where CWEZnnn is your userid) For the main steplib: DSN=SYS2.CW.&CWGACX..SLCXLOAD For the concatenated steplib: DSN=CWEZ000.TOPAZ.TTT.PDSE.LOAD Note: To add a new blank line above a given line, place the cursor at the beginning of a line, and press Enter. Note: View panes may be resized for your convenience. To learn how, see Appendix C. 16

17 37. Close the tab by clicking on the X and selecting Yes. A quick look at the stubs reveals one program stub for the CWKTDATE-called program. There are also two I/O stubs: one for the VSAM read and one for the QSAM write. 38. Double-click the name to look closer. 17

18 Here we see the program stub for the CWKTDATE-called subprogram: 18

19 This is the stub for the input file, which contained 11 records: This is the stub for the report/output file: 19

20 The 22 records written include header and detail lines as well any blank lines. Next, look at the scenario that was built to run the unit test. 39. Double-click to open the scenario. See the four tabs along the bottom where the input data is shown. 20

21 The Stubs tab allows stub selection and deselection for use in the unit test. 21

22 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. 22

23 The Information tab gives additional notes for team testing. 40. Click on the Input Data tab. 23

24 41. Select the Run Test Scenario icon on the toolbar. Run Test Scenario R Note: The Run Test Scenario icon is also displayed on the Stubs, Assertions and Information toolbars. 42. In the Test Run dialog box that appears, verify that Runner.jcl is highlighted, then check the boxes for Use stubs and Delete temporary files. 43. Click OK. 24

In the Xpediter debugger, you will create a debug configuration to run a program and generate its unit test.

25 A status box similar to the one below will appear. Scroll through the various reports to learn about your completed unit test. GENERATING A UNIT TEST In this workshop, you will generate a program unit test. In the Xpediter debugger, you will create a debug configuration to run a program and generate its unit test. In the Project Explorer, you will modify the JCL and run a unit test. 1. Open the Xpediter perspective, then reset the perspective. 2. Close the Cheat Sheet tab and all tabs that are not part of the Xpediter perspective. Your clean perspective should look like the one shown here. 25

26 Note: Anything in view that is not part of the Xpediter perspective would be activity by a previous user. 3. Click Run on the menu bar at the top, then choose Debug Configurations 26

The new configuration template should look like the one shown here.

27 4. Single-click on Xpediter Batch Debug Session to highlight this session type. 5. Click on the New Launch Configuration icon to proceed. The new configuration template should look like the one shown here. Note: The enlargement shows the name field on the top left. Your default name should be similar. 27

Look at the Host Connection field to verify the correct LPAR, which should be TestDrive.

28 6. Change the Name at the top to a name of your choosing. The enlargement shows that this launch configuration has been named MY_DB2_Config. 7. Look at the Host Connection field to verify the correct LPAR, which should be TestDrive. Note: You may or may not find a drop-down list for this field. If so, be sure to choose CWCC. 8. Find the Job to Debug Dataset(member) field, which should be blank. 28

29 9. Enter this dataset name: CWEZ000.CX.R SMPE.SLCXCNTL(RUNSAMP1). 10. Select Autofill to populate the Job name and Steps/programs fields. 29

30 The results should show the information seen here. The Target tab is now complete. We will look at two of the other tabs. 30

This speeds up unit test generation by not setting breakpoints

31 11. Select the Breakpoints tab, then choose the button for Load the main module only. This speeds up unit test generation by not setting breakpoints and stopping in called programs. 12. Select the DDIO tab, and add the dataset SALESSUP.TTT.SHRDIR. 31

32 13. Click Apply and then Debug. The Xpediter execution of the program will begin and many of the Xpediter perspective views will be populated. 32

33 In the program source view, the main program will be paused at the procedure division. 14. Right-click in this view to display the context menu, then choose Generate Unit Test 33

34 15. When the Generate Unit Test box appears, click New to name this project. 16. Name the project Project_cweznnn, where cweznnn is replaced by your assigned TSO userid, and click Finish. Note: The enlargement shows the project name for TSO userid cwez

35 17. Back on the previous screen, check the boxes for Generate program stubs, Generate I/O stubs and Generate DB2 Statement stubs. 18. Accept the other defaults, then click OK. 19. Returning to the program source view, press F8 to resume processing. This may take a few minutes. 35

To run the unit test, open the Host Explorer perspective.

36 20. If the program does not terminate but stops processing at the GOBACK, press F8 to complete the execution. The Unit Tests Generation is now complete. 21. To run the unit test, open the Host Explorer perspective. The enlargement shows the Host Explorer tab in the upper right. Note: If this is not the case for you, simply click Compuware in the menu bar at the top, and choose Host Explorer from the dropdown menu. 36

37 22. Next, select the Project Explorer tab. 23. Locate and expand your project entry. In this example, the project is Project_cwez

Therefore, both sets of JCL must be prepared.

38 When generating the unit test, all stubs were created. The test execution will be done both with and without stubs. Therefore, both sets of JCL must be prepared. It is beneficial to set up a job card that will be appended automatically to the prepared JCL. 24. To do this, choose Window from the menu bar at the top, then select Preferences. 38

The job name should be your assigned TSO userid plus one character.

39 25. Navigate to the Compuware preferences, then select Topaz for Total Test. 26. Verify and/or change the jobcard to match the one shown below. The job name should be your assigned TSO userid plus one character. The job identification string should be USERZ plus the three numeric digits at the end of your assigned TSO userid. For example, for TSO userid CWEZ001, the job name could be CWEZ001T, and the identification string should be USERZ When complete, click Apply then OK. 39

statement to match what is shown here in this enlargement box.

40 28. Double-click Runner.jcl to open an edit session, as shown. 29. If necessary, modify the first two lines of the //STEPLIB DD statement to match what is shown here in this enlargement box. Do the same for the //SLSF001, //EMPFILE and //RPTFILE DD statements. 40

These DD statements appear below: //STEPLIB DD DISP=SHR,DSN=SYS2.CW.&CWGACX..SLCXLOAD // DD DISP=SHR,DSN=CWEZ000.CX.R170000.SMPE.SLCXLOAD //SLSF001 DD DSN=SALESSUP.TTT.

41 These DD statements appear below: //STEPLIB DD DISP=SHR,DSN=SYS2.CW.&CWGACX..SLCXLOAD // DD DISP=SHR,DSN=CWEZ000.CX.R SMPE.SLCXLOAD //SLSF001 DD DSN=SALESSUP.TTT.SHRDIR,DISP=SHR //EMPFILE DD DSN=CWEZ000.CX.R SMPE.SLCXCNTL(TTTDATD),DISP=SHR //RPTFILE DD SYSOUT=* Note: The two dots following &CWGACX are correct. 30. When changes are complete, click the X on the tab to close the edit session. 31. Then click on Yes in the confirmation box to save the changes. 41

42 Double-click RunnerDb2.jcl to open an edit session.

43 33. Scroll down to view //STEPLIB and //SYSTSIN. You may need to change both areas as well as other DD statements. For steps 34, 35 and 36 below, use the following DD statements: //STEPLIB DD DISP=SHR,DSN=SYS2.CW.&CWGACX..SLCXLOAD // DD DISP=SHR,DSN=CWEZ000.CX.R SMPE.SLCXLOAD //RPTFILE DD SYSOUT=* //SLSF001 DD DSN=SALESSUP.TTT.SHRDIR,DISP=SHR //EMPFILE DD DSN=CWEZ000.CX.R SMPE.SLCXCNTL(TTTDATD),DISP=SHR //SYSTSIN DD * DSN SYSTEM(DBCC) RUN PROGRAM(TTTRUNNR) PLAN(CWKTDB2X) PARMS( /NOSTAE ) END /* NOTE: The two dots following &CWGACX is correct. 43

34. If necessary, modify the //STEPLIB as shown: Note: The two

If necessary, modify the //RPTFILE, //EMPFILE and //SLSF001 DD

If necessary, modify the //SYSTSIN as shown: 37.

44 34. If necessary, modify the //STEPLIB as shown: Note: The two dots following &CWGACX are correct. 35. If necessary, modify the //RPTFILE, //EMPFILE and //SLSF001 DD statements as shown: 36. If necessary, modify the //SYSTSIN as shown: 37. When changes are complete, click the X on the tab to close the edit session. 38. Select Yes in the confirmation box to save the changes. 44

45 With the JCL modifications complete, you are now ready to run a test. 39. Locate and double-click Scenario in your project. 40. Locate and select the Run test scenario icon. The initial test run will use all of the stubs created during unit test generation. 45

46 41. Highlight Runner.jcl, and check the Use stubs and Delete temporary files boxes. 42. Click OK when complete. 43. When the test run has finished, view the Test Suite Summary. Your Success rate should be 100%. 46

47 Note: The Stubs Executed information near the bottom of the report. Here you see the stub information in a side-by-side comparison. 47

48 44. Return to your scenario, and activate the Stubs tab along the bottom of the section. We want to run the test again without using stubs. 45. Remove all stubs from the Selected window. It should be completely empty. 48

49 46. Locate and click on the Run test scenario icon. 47. Highlight RunnerDb2.jcl, and uncheck the box for Use stubs. 49

Instead, we will use a different input file. 49. Double-click RunnerDb2.

50 48. When the test run has finished, view the Test Suite Summary. Your Success rate should be 100%. We will now rerun the test without using stubs. Instead, we will use a different input file. 49. Double-click RunnerDb2.jcl to open an edit session. Change the input file (//EMPFILE DD statement) member name from (TTTDATD) to (TTTDAT2). 50. Save your changes. 50

51 The resulting report should show two failures indicated in red text. Enlargements are shown below. 51

52 Note: The file used had two additional records that account for the difference in the grand totals. To remedy this situation, return to the Scenario, and select the Assertions tab. 51. For the GRAND_TOTAL, click in the Comparison column, and choose noassert from the dropdown list. Noassert bypasses testing. 52. Do the same for the TOTAL_RECORD. 52

53 53. Click the Run test scenario icon and then Yes in the modified scenario confirmation box. 54. Highlight RunnerDb2.jcl, and leave the box for Use stubs unchecked. 53

54 This time the report will show that two tests have no failures. Congratulations! You have completed the Topaz for Total Test section. The appendices begin on the next page. 54

APPENDIX A: DATASET FILTERS The Topaz Workbench Host Explorer provides lists of datasets and databases. These lists are used for subsequent processing such as editing and copying.

55 APPENDIX A: DATASET FILTERS The Topaz Workbench Host Explorer provides lists of datasets and databases. These lists are used for subsequent processing such as editing and copying. They function similarly to standard TSO/ISPF option 3.4. Filtering is a way to limit or customize a list, and multiple filters may be used concurrently. In the Host Explorer directory below, the z/os Datasets entry has been expanded, revealing numerous filters. 55

f*, and click OK to display a list of all z/os datasets in this LPAR with dataset names

56 1. Leaving the z/os Datasets entry highlighted, right-click to display the context menu, and select Add Filter. 2. In the Add Filter box, add cwt010.f*, and click OK to display a list of all z/os datasets in this LPAR with dataset names that begin with cwt010.f followed by any additional characters. The expanded filtered list should look like this: 56

APPENDIX B: OPENING PERSPECTIVES Topaz Workbench is Eclipse-based and uses numerous universal Eclipse perspectives as well as an increasing

In the screenshot below, Topaz Workbench has the Xpediter perspective open and in view.

57 APPENDIX B: OPENING PERSPECTIVES Topaz Workbench is Eclipse-based and uses numerous universal Eclipse perspectives as well as an increasing number of Compuware perspectives. All perspectives follow a common set of standards. In the screenshot below, Topaz Workbench has the Xpediter perspective open and in view. Other currently open perspectives are shown on the tabs to the upper right. Right-clicking on a perspective opens a display with various actions for that perspective. The Reset command is valuable, especially when several views have been resized and/or moved. 57

58 To access and open all available perspectives, choose Window from the main navigation, and select Open Perspective to display a list. Similarly, a list of Compuware perspectives may be displayed by choosing Compuware from the main navigation. 58

icons. If a second monitor is available, you can also grab the tab and drag it to that monitor.

59 APPENDIX C: RESIZING VIEW PANES Most Eclipse perspectives display multiple viewing panes that contain abundant information. The panes commonly use horizontal and/or vertical scroll bars to reveal more content and can be resized by dragging the edges or using the standard resize icons. If a second monitor is available, you can also grab the tab and drag it to that monitor. The Test Scenario viewing pane is contained within the entire Host Explorer perspective. To maximize the content in the Test Scenario viewing pane, you click the Maximize icon. If you hover over the icon, it displays the corresponding Maximize tool tip. 59

clicking the Restore icon in the top right corner of the

60 The Test Scenario viewing pane then takes over the window. You can restore the viewing pane to its original size by clicking the Restore icon in the top right corner of the viewing pane. If you hover over the icon, it will display the Restore tool tip. 60

61 To display tabs on a second monitor, grab the tab and drag it to your other monitor. This completes the Topaz for Total Test tutorial for Compuware Test Drive. NEXT STEPS Take a deep dive into other Topaz functionality if you haven t already. Pick your next tutorial: File and Data Management Code Analysis and Debugging Source Code Management, Release Automation and Deployment Automation 61

Getting Started with Xpediter/Eclipse

Getting Started with Xpediter/Eclipse This guide provides instructions for how to use Xpediter/Eclipse to debug mainframe applications within an Eclipsebased workbench (for example, Topaz Workbench, Eclipse,