How to use the Cobertura and reflection mechanisms to improve code coverage in Java unit tests

Introduction

Unit testing is an important part of quality assurance in the process of software development. Unit tests can reduce the cost of software maintenance by reducing potential bugs in your code and making them discovered earlier. The quality of the software code is guaranteed by unit test, and the quality and efficiency of unit test cannot be neglected. Improving the quality and efficiency of unit testing not only makes software code more secure, but also saves time for developers to write or modify unit test code. Measurement of unit Test quality and efficiency of the indicators are diverse, code coverage is one of the most important indicators. In general, the higher the Code coverage, the larger the scope of the unit test coverage, the less the number of potential bugs in the code, the higher the quality of the software. This paper first introduces the code coverage of the statistical indicator types and common statistical tools, and then focus on the selection of representative line coverage for analysis, introduced two methods to improve the line coverage of code.

Statistical metrics for Code coverage

Code coverage refers to a way to measure the extent of code coverage, usually by means of statistical analysis of the following:

Row overlay. It is also called statement overlay or base block overlay. This is a more common and representative metric that measures whether each executable statement in the measured code is executed.

Conditional coverage. It measures whether the presence of a branch in a current code can cover both the entry and the absence of the branch. This requires the developer to write multiple test cases to satisfy both the entry and the not-into branches.

Path overlay. It measures the entire path produced by different combinations of branches when there are multiple branches in the current code. This is one of the strongest coverage detections, whereas conditional overrides are only part of the path overlay.

In these three coverage indicators, the line coverage is simple, wide applicability, but may be considered as the "weakest coverage", but it is not. Row overlays are overridden relative to a condition or path, allowing developers to overwrite as many code as possible with as few test data and use cases. In general, it is through the tool to test the entire project unit testing of the row coverage, and then for the code has not been covered, analysis of the reason it has not been covered. If the branch is not overwritten because it does not meet the criteria for entering the branch, the developer will further modify or add the test code to complete the condition or path coverage for that part.

It can be seen that high efficient and high quality row covering is the precondition of effectively covering the condition and the path. The higher the line coverage, the less code that is not covered, so that the developer will focus on modifying the test case to cover a small amount of code. Conversely, if the line coverage is low, the developer needs to examine the code that is not covered individually, and the effort is dispersed, making it difficult to improve the quality of the remaining code unit tests.

Code Coverage = number of lines of code measured/reference code total line * 100%. It can be seen from the calculation of code coverage that to improve code coverage, you can increase the number of lines of code being measured, or reduce the number of rows in the parameter. From these two angles, we will analyze how to increase the number of lines measured and reduce the total number of parameters of the code.

Use Cobertura statistics and increase line coverage for code

Cobertura is an excellent open source test coverage statistics tool that combines with unit test code to mark and analyze what code is executed and what code is not executed and the conditional branches that pass through the test package to measure test coverage. In addition to finding code that has not been tested and discovering bugs, Cobertura can also optimize the code by marking unwanted, executed code, resulting in a beautifully detailed HTML coverage test report.

The Cobertura Basic Toolkit has four basic processes and corresponding tools: Cobertura-check, Cobertura-instrument, Cobertura-merge, Cobertura-report; This script is more cumbersome and inconvenient to use independently and is not conducive to automation. However, Cobertura on the Maven compiler platform has the corresponding Cobertura-maven-plugin plug-ins, so that the code compilation, detection, integration and other cycles can be automated pipelining.

The official version of Cobertura-maven-plugin has five main target directives (goal), as shown in table 1:

Cobertura is usually used with Maven. Therefore, if the engineering directory structure follows the criteria recommended by Maven, an integrated Cobertura base POM file is shown in Listing 1:

Listing 1. The basic structure of the POM file

<project> 
  <reporting> 
     <plugins> 
        <plugin>
          <!--used to integrate Cobertura plug-ins into Maven--> 
          <groupId>org.codehaus.mojo</groupId>
                <artifactid>cobertura-maven-plugin </artifactId>
                <version>2.5.2</version> 
         </plugin> 
      </plugins>
   </reporting> 
</project>

If the engineering directory structure does not adopt the Maven recommendation criteria, the following additional settings are required:

Listing 2. Project directory structure configuration for Maven

<build> 
     <!--The path configuration of Java source code-->
     <sourceDirectory>src/main/java</sourceDirectory>
     <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory> 
     < path configuration for!--test code-->
     <testSourceDirectory>src/test/java</testSourceDirectory> 
     <!--The path configuration of the compiled class file of the source code--> 
     <outputDirectory>target/classes</outputDirectory>
     <!--test source code compiled class file path configuration-->
     <testOutputDirectory>target/test-classes</testOutputDirectory>
     <plugin> .... </plugin > 
 </build>