In this article, i am going to explain how to use SonarQube and JaCoCo as a Code Coverage and Source Code Quality analysis tool for Spring Boot application.
What is Code Coverage and why it is important?
I am using the Jacoco Maven plugin version 0.8.1 (With Java 8 / Maven 3.1.0). Cannot get Jacoco to work with path exclusions. I would like to exclude these packages: my.package.model my.package. Maven Jacoco Configuration - Exclude classes/packages from report not working maven configuration jacoco jacoco-maven-plugin I have a maven multi-module project and I'm using jacoco-maven for code coverage reports.
Code Coverage is an important topic when it comes to Test Driven Development (TDD). most of the developers are curious to know how percentage of source code is covered with test cases developed (for both unit and integration tests).
Code Coverage shows the stats of how much of source code is covered and tested with test cases (both unit and integration) developed for the application. Therefore the code coverage analysis is an important fact of measuring the quality of the source code. we need to write the test cases to achieve higher code coverage which will increase the maintainability of the source code.
Technology Stack
The following technologies will be used for this article.
- SonarQube
- Docker
- JaCoCo
- Spring Boot Application with maven
Install and Run SonarQube with Docker
The most of the developers know the “SonarQube” as a code quality analysis tool. This has the capability of the executing Unit and Integration tests with given library/tool (such as Cobertura, JaCoCo etc..) and it gives a detailed analysis of code coverage of the source code. In this article, we will run SonarQube as a docker image. Therefore we need to have docker installed in our development environment.
If you do not have SonarQube in your local development environment, you can download it with following command.
Once the SonarQube docker image is retrieved, it can be run with following command.
This will start a docker container based on the sonarqube image and give it the name sonarqube. Adding the -d means the container will run in detached mode (background). The -p 9000:9000 and 9092:9092 means that we expose port 9000 and 9092 to the host using the same port numbers.
Now you can navigate to http://localhost:9000 and you will see your local SonarQube dashboard.
JaCoCo Maven configuration
JaCoCo is a one of the famous code coverage library available for java based applications. In oder to add JaCoCo for the project, you have to add the following maven plugin (under the plugins) for the pom.xml of the project.
| <plugin> |
| <groupId>org.jacoco</groupId> |
| <artifactId>jacoco-maven-plugin</artifactId> |
| <version>0.8.0</version> |
| <executions> |
| <execution> |
| <id>default-prepare-agent</id> |
| <goals> |
| <goal>prepare-agent</goal> |
| </goals> |
| </execution> |
| <execution> |
| <id>default-report</id> |
| <phase>prepare-package</phase> |
| <goals> |
| <goal>report</goal> |
| </goals> |
| </execution> |
| </executions> |
| </plugin> |
(This should be added under the plugins section of the pom.xml of the project)
JaCoCo Test Coverage Analysis with SonarQube
First you need to run the test cases with maven before sending the report for the Sonar server. This can be done with following command.
SonarQube has a really good integration with test code coverage. It allows you to analyze which parts of the code should be better covered, and you can correlate this with many other stats. If you want to send your report to your Sonar server the only thing you need to do is to execute the following command in the terminal. (make sure that you have run the mvn test command successfully before executing the below command)
Then it will send the inspection report to the SonarQube and you can access thedetailed report through http://localhost:9000 using the specified login credentials.
username : admin
password : admin
Run as a Single Command
As you can see that we have used two separate commands for integrating test result analysis with sonar.
Running test cases with maven
Sending the coverage report to sonar
Both of above commands can be composed into one single command as follows.
Exclude Classes from Code Coverage Analysis
In the code coverage analysis we focus only about the classes that should be covered with unit and integration tests. that mens the controllers, repositories, services and domain specific classes. There are some classes which are not covered by either unit or integration tests. In order to get the correct figure of code coverage analysis, it is required to exclude those non related classes when performing code coverage analysis.
E.g:- configuration related classes (SpringBootApplication configuration class, SpringSecurityApplication configuration class etc..) should be avoided
This can be done with adding the classes as classes to be excluded under the “properties” section of pom.xml.
You can add multiple exclusions and each of them should be separated by comma. According to the above configuration, SpringBootDockerExampleApplication and any class under the config package will be excluded/ignored when performing code coverage analysis.
Code Coverage Preferences
Exclude From Code Coverage
The behavior of the EclEmma plug-in can be adjusted in the Eclipse Preferences dialog. Open the dialog from the Window → Preferences menu. EclEmma's settings are located on the page Java → Code Coverage. Or simply type coverage in the filter field. The Code Coverage preferences page contains the following options.
- Open coverage view automatically: Whenever a new coverage session becomes active the Coverage view can be automatically shown in the current workbench window. (Default: on)
- Activate new coverage sessions: A new session is created when a coverage launch terminates or a session is imported. This option determines whether the new session should become automatically active, i.e. its result data is shown in the coverage view and in the Java editors. (Default: on)
- Remove coverage sessions for removed launches: Coverage session will be available until they are manually deleted in the Coverage view. For frequent test runs it might be more convenient to remove them automatically with the associated launches. (Default: off)
- Reset execution data on dump: For a running application coverage data can be dumped at any time from Coverage view. This option determines whether execution data is reset after such an intermediate dump. (Default: off)
When a launch configuration is executed in code coverage mode the first time EclEmma selects class path entries that will be in scope for code coverage analysis by default. There are several options to modify the default selection behavior:
- Source folders only: Consider source based class path entries only. (Default: on)
- Same project only: Pick only class path entries from the same project. This option works only for launch configurations that have a project associated, i.e. Java applications. (Default: off)
- Only path entries matching: Comma separated list of strings that must match with the class path entry. A class path entry matches the filter, if it contains one of the given strings. (e.g. 'src/main/java', Default: no filter)
Warning: If your settings do not match any of the class path entries in your project(s), every new launch in coverage mode will have an empty analysis scope.
Jacoco Includes Excludes
For technical reasons it might be necessary to exclude certain classes from code coverage analysis. The following options configure the coverage agent to exclude certain classes from analysis. Except for performance optimization or technical corner cases these options are normally not required.
- Includes: A list of class names that should be included in execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?). (Default: *)
- Excludes: A list of class names that should be excluded from execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?). (Default: empty)
- Exclude classloaders: A list of class loader names that should be excluded from execution analysis. The list entries are separated by a colon (:) and may use wildcard characters (* and ?). This option might be required in case of special frameworks that conflict with JaCoCo code instrumentation, in particular class loaders that do not have access to the Java runtime classes. (Default: sun.reflect.DelegatingClassLoader)
Warning: Use these options with caution! Invalid entries might break the code coverage launcher. Also do not use these options to define the scope of your analysis. Excluded classes will still show as not covered.
Other Relevant Preference Pages
Java elements in the various Eclipse views like the Package Explorer might be directly decorated with coverage data from the current session. This can be enabled on the page General → Appearance → Label Decorators. The corresponding entry is
- Java Code Coverage (Default: off)
The annotation style for code coverage in editors can be adjusted on the page General → Editors → Text Editors → Annotations. The corresponding entries are:
- Full Coverage (Default: green highlighting)
- Partial Coverage (Default: yellow highlighting)
- No Coverage (Default: red highlighting)