This lab guides you how to review code coverage reports and dashboards as Tammy, the test manager.
You can see that both applications have the Aggregated Code Coverage over 70% but Perfect Calculator is in warning state while SAM Application is in normal state. The code coverage report is a roll-up percentage of code coverage from all builds within one workbook. ADI allows users to define the code coverage threshold for a workbook to customize based on the quality level that application required.
For example in this lab, the code coverage for Perfect Calculator which is lower than 80% will be shown in yellow to indicate the warning status and the code coverage which is lower than 50% will be shown in red to indicate that it is not in acceptable number. For the SAM Application, the Aggregated Code Coverage which is lower than 70% will be shown in yellow.
These threshold values can be set when you create the workbook. See Setting up Manual Builds for Code Coverage Analysis how to set up the threshold values.
Currently there is only one build, Perfect Calculator Manual Builds for the Perfect Calculator workbook. The reports show the code coverage analysis for the latest build of Perfect Calculator Manual Builds.
The first report shows that the Perfect Calculator has 75% Code Coverage which is in the warning area. Looking at the next report, the Code Coverage Percentage Trend is starting to go down from Nov 12. On the next report, the number of total executable lines in the next report is going up from 64 to 76 on 11/13/2015 and then to 87 on 11/17/2015. However, the executable lines hit remains quite stable. There seems to be some code coverage issue with the last two builds of the Perfect Calculator Manual Build.
The Coverage Changed vs Unchanged Code report indicates that there are fifteen executable lines changed within a build and none of them have been tested. This means the changed code has not been tested properly.
The Files Analysis view appears. By default, this view shows the files that the code coverage is below the insufficient threshold value for the current build, which is 2015Nov17Build. You can immediately see the files that have code coverage issues from this view.
On the top row of this view, you can see the summary of the entire build: code coverage percentage, number of modified files, number of new files, number of historical tests files ran against this build, and number of minimal tests to run.
You can see the same information as in the Workbook view that the code coverage drops by almost 11%. There is one file updated for this build.
You can notice that CLCTPCTB.cbl status is in red warning and the percentage of code coverage change goes down by 18%. From the total of 39 executable lines, there are 11 executable lines added and 4 lines updated to the build. You suspect that these added and updated executable lines that didn't get tested cause the code coverage of the file to go down 18%.
Similar to the Files Analysis view, this view shows the code coverage detail for all flowpoints within a file. You can see that the code coverage of COMBINE-AND-WRITE is showing 0% and 15 executable lines from the total of 16 executable lines are either added or updated. This confirms Tammy suspicion that the executable lines that are modified within the CLCTPCTB.cbl are not tested.
On the page for 2015Nov12Build, the code coverage for overall build indicates 100% code coverage. This build has been fully tested. The issues seem to be arisen starting in 2015Nov13Build. Tammy wants to compare the builds to get a better understanding of what has changed.
The Compare Builds page appears. By default, 2015Nov12Build is preselected.
Click Compare to compare the three builds.
On the Compare Build view, you can compare the detail of three builds in one view. This view helps confirm that your observation earlier that file CLCTPCTB.cbl has brought the code coverage percentage of the entire build down from 100% to 86% and 75%. The cause could be that the executable lines that are added to the CLCTPCTB.clb in the past 2 builds have not been properly tested. You can also see that the code coverage percentage of PERFCALC.cbl also drops 2% on 2015Nov13Build. There are 2 execution lines added but it seems not tested either.
You can see that for 2015Nov13Build, P-INPUT-AZUE0000 and P-OUTPUT-AZUE0000 are newly added to the file but they have not been tested. P-INPUT-AZUE0000 is removed from 2015Nov17Build and COMBINE-AND-WRITE is added to the build. Again the new flowpoint has not been tested either. These 2 flowpoints are areas that require testing.
Tammy is now satisfied with her investigation on the code coverage issue for Perfect Calculator application. She communicates the results to her team and asks Trish to update the tests to cover P-OUT-AZUE0000 and COMBINE-AND-WRITE flowpoints. She also suggested her team to use ADI to always check the code coverage reports to ensure that the application is fully tested.