Summary: This article describes how to estimate the project’s source code coverage with code review. The article also gives an outline of how to make the most from Review Assistant’s Code Coverage report.
As from version 2.6, Review Assistant, Devart’s code review tool, provides the new Code Coverage report. Developed in response to numerous requests from our customers, the report serves for a better quality control over the code review process. Within the context of this article, we would like to show how to effectively use the tool. In particular, we will elaborate on how to:
- Exclude excessive data from a report with filtering
- Group report data
- Interpret report results
Overview of Code Coverage Report
First, let’s create the Code Coverage report:
- In Visual Studio, click the Review Assistant Reports button on the Review Assistant toolbar
- In the Report box, select Code Coverage
- In the Project box, select a project
- Use the Date Picker control to select the report time period
- Click View Report
The opened Code Coverage report looks in the following way.
As we see, the report combines data from the project repository with the data on preformed reviews. The Status column shows whether the given revision was reviewed or not. Also, the Linked Reviews column allows to quickly navigate to the Code Review Board and view the details of a particular review.
Preparing Code Coverage Data for Analysis
By looking at Figure 1, it becomes obvious that not all revisions should be put into consideration when estimating the coverage of the review project. Even such small commit range includes two commits, that were automatically generated by Git source control. Therefore, to prepare data for analysis, we need to:
- Exclude revisions with automatic merges – usually, such revisions do not include users’ edits.
- Eliminate revisions, that were created by a Continuous Integration Server. As a rule, these revisions represent the change of project version after a night build.
To achieve the aforesaid goals, we will use filtering. Click Edit Filter and create a filter, similar to the one, that is shown in Figure 2.
The filter in Figure 2 can be interpreted in the following way: the commit comment should not include the “Merge” word, and anyone can be an Author, except AlmBuildBot (a virtual user, created for CI Server needs).
Estimating the Total Number of the Reviewed Revisions
Now our report contains meaningful revisions. So, we can estimate how many revisions passed through code revision. In this regard, we need to group the report by the Status column. Right-click the header of the column and select Group By This Column from the popup menu (see Figure 3).
After grouping, the report will look in the following way.
As you see in Figure 4, the selected time period includes revisions, that are currently reviewed. However, it is clear that 40,6% of them stay unreviewed. Therefore, 60% of code in our example has been reviewed.
Important Note
When it comes to the Code Coverage report, it is important to say, that we estimate the number of reviewed revisions, not code lines. Our estimation of the reviewed code volume is based on the presumption, that all revisions are approximately of the same size. Also, we presume that the project code is reviewed on a regular basis, not from time to time (in the latter case, there is no sense to estimate statistics at all).
Conclusion
We have reviewed the main features and benefits of the Code Coverage report, implemented in Devart’s code review tool, as well as the ways to analyze the code coverage report data. We hope it helps you improving control over code review process. Download Review Assistant and start reviewing code today.
