Guru: RDi Code Coverage Without SEPs

August 12, 2019 Susan Gantner

My last Guru tip provided an introduction to RDi’s Code Coverage tool that you can use to determine how complete your tests are. In that tip I discussed how to run it using Service Entry Points (SEPs). In this follow-on tip, I’ll continue the exploration of this tool with some additional details plus introduce you to an alternative way to run a Code Coverage session.

Before going into the alternative approach to running Code Coverage, there are a few details I didn’t mention in the first tip.

I mentioned that Code Coverage uses the debug engine. What I didn’t mention at that time was that in order for programs to have their testing data gathered, they must have been compiled for debug, using either *Source, *List or *All for the Debug View option for xxxLE members. Non-ILE language members must use either *SRCDBG or *LSTDBG.

Also related to the debug connection, remember before running code coverage to check the option on the IBM i Debug Preference page for “Update production files.” If you need to specify that when debugging, you’ll also need it here and setting the preference is the easiest way to ensure you don’t forget. It may not be obvious that this preference applies to Code Coverage as well as debug, but it does.

Merged Reports For Multiple Test Runs

Sometimes to cover all the features of an application, multiple test runs of the same program(s) are required. Looking at the reports for individual test runs will inevitably show incomplete coverage, but how can you tell how much code you have covered in total over multiple test runs? To produce a complete report, select multiple result entries in the Code Coverage Results view (hold down the Ctl key) then right click on the selections and choose “Open”. The subsequent report that will appear in the editor view will be a merger of the coverage data of all the selected entries.

Running Code Coverage Using A Manual Configuration

Last time I covered how to run Code Coverage using Service Entry Points (SEPs). This time we’ll look at how to do it using a manually created configuration.

Why would you want (or need) to do this? There are some limitations when using SEPs. The most significant one is that the initial program must be an ILE language program (e.g., it cannot be CLP or RPG400.) You could create a CLLE or RPGLE program that simply calls the CLP or RPG400 program for the SEP.

Alternatively you can manually create a configuration that will call the program for you. Some people prefer to use manually created configurations – both for debug and for Code Coverage. While I lean toward using SEPs almost always when I’m debugging, I use manual configurations a bit more often for Code Coverage. The reason for this is that I need to test the same group of programs over and over after making changes. So my Code Coverage configurations tend to get reused more often than debug configurations, which tend to be one-shot situations.

Let’s look at Code Coverage testing with a manually created configuration. Here’s the big picture. Details for each step follow in the text.

1. Start either a batch or interactive configuration from a program you want to analyze.
2. If needed, give the configuration a meaningful name and add any additional programs for analysis in the configuration dialog and.
3. Specify a command to start the application containing the program(s) to be analyzed.
4. Save the configuration and the program will automatically run. For interactive configurations you will need to associate an interactive job to your RDi session before running the test.
5. When the programs finish running, the Code Coverage Results view appears and the editor window is populated with a report.
6. For Interactive configurations, you may need to release the interactive job from its connection to RDi.

Step 1: When it comes to creating my own configuration with RDi for debugging, I prefer to use the “Debug (Prompt) > IBM i Job” option as I explained in an earlier tip. However, the “job” option that I described in that tip doesn’t exist for Code Coverage and would tend to make the configuration less flexible for future tests. I can still create either an Interactive or a Batch configuration. Right click on the first program name you want to test (as we did previously for the SEP) and choose “Code Coverage (Prompt)” followed by either Batch or Interactive. Since my program has a display file, I’ll choose Interactive.

Step 2: A dialog similar to the one in the figure below will appear. You can change the configuration name if needed to make it recognizable later. Note that you can add additional programs or service programs in the first tab of the dialog if needed. Only programs or service programs listed here will have data collected for coverage analysis.

Step 3: Before leaving this dialog, check the tab labeled “How To Start” to ensure it contains the best command to use to run your test. When using a configuration, this command will be used to call the program for your test automatically. By default it is just a simple CALL statement to the initial program for an interactive configuration. For a batch configuration, it will be a SBMJOB command containing the CALL statement. You can change the command if necessary.

Step 4: When you’re happy with the programs to be analyzed and the command to start the testing process, press the “Apply” button to save your configuration and then press “Coverage” to begin the test. If it’s a batch job, the job will be submitted and the command run based on what was specified in the previous step. If it’s an interactive configuration, you may see the message: “No interactive job associated with this connection. Associate an interactive job with this connection to continue.”

Chances are you’ve had experience with this message and the process to associate an interactive job with RDi. To do this you simply go to an interactive “green screen” job and enter the command STRRSESVR with the name of your RDi connection (that name will be in the message). This will briefly show an “RSE Communications Server” screen and will subsequently call your program using the command you specified in the configuration. From there, just run your test, interacting with the program(s) to be tested as necessary. Note that only programs listed in the Code Coverage configuration will have data collected for coverage analysis.

Step 5: When the program(s) you’re analyzing end, the Code Coverage Results view appears and the editor window is populated with the summary report. Double click on any program in the report to see the source level detail. The Code Coverage Results view will also be populated with an entry for the results of your run. Remember that if you want to see a merged report spanning multiple test runs, select multiple entries from the Code Coverage Results view and choose “Open” from the context menu.

Step 6: If you associated an interactive job for testing, you should now release that job from its connection to RDi. To do this, right click on the “Objects” subsystem in the Remote Systems view (Objects is immediately under your connection name) and from the context menu, choose “Release Interactive Job.”

Your manual configurations are saved. Next time you want to do another test run on the same set of programs, you can choose “Compiled Code Coverage Configurations” from the Run menu in RDi. Choose from the list of saved batch and interactive configurations and press the Coverage button to begin a new test run.

More Code Coverage To Come

You’ve seen how to start a Code Coverage session using either SEPs or a manual RDi configuration. There’s a third option – you can start a Code Coverage session using a CL command. In a future tip, I’ll cover how and why you may want to do that.

Susan Gantner, an IBM Champion and co-author of the popular Redbook, Who Knew You Could Do That with RPG IV, is one of the top speakers/writers/trainers on IBM i development topics. She is a partner at Partner400 and System i Developer, and she hosts the RPG & DB2 Summit twice per year with partners Jon Paris and Paul Tuohy.

RELATED STORIES

Guru: How Thorough Was Your Last Test? RDi Code Coverage Can Tell You

Three Little Words That Simplify Debugging

RDi Debug Without SEPs