Exclusions from Jacoco Report

1. Introduction

In this article, we'll see how to exclude certain classes and packages from JaCoCo test coverage reports.

Generally, the candidates for exclusion can be configuration classes, POJOs, DTOs as well as generated byte code. These carry no specific business logic and it could be useful to exclude them from the reports in order to provide a better view of test coverage.

We'll explore various ways of exclusion in both Maven and a Gradle project.

2. Example

Let's start with a sample project where we have all the required code already covered by tests.

Next, we'll generate the coverage report by running mvn clean package or mvn jacoco:report:

Here, this report shows that we already have the required coverage, and missed instructions should be excluded from JaCoCo report metrics.

3. Excluding Using Plugin Configuration

Classes and packages can be excluded using standard * and ? wildcard syntax in the plugin configuration:

• * matches zero or more characters
• ** matches zero or more directories
• ? matches a single character

3.1. Maven Configuration

Let's update the Maven plugin to add several excluded patterns:

<plugin> 
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <configuration>
        <excludes>
            <exclude>com/baeldung/**/ExcludedPOJO.class</exclude>
            <exclude>com/baeldung/**/*DTO.*</exclude>
            <exclude>**/config/*</exclude>
        </excludes>
     </configuration>
     ...
</plugin>

Here, we've specified the following exclusions:

• ExcludedPOJO class in any sub-package under com.baeldung package
• all classes with names ending in DTO in any sub-package under com.baeldung package
• the config package declared anywhere in the root or sub-packages

3.2. Gradle Configuration

We can also apply the same exclusions in a Gradle project.

First, let's update the JaCoCo configuration in build.gradle and specify a list of exclusion, using the same patterns, as earlier:

jacocoTestReport {
    dependsOn test // tests are required to run before generating the report
    
    afterEvaluate {
        classDirectories.setFrom(files(classDirectories.files.collect {
            fileTree(dir: it, exclude: [
                "com/baeldung/**/ExcludedPOJO.class",
                "com/baeldung/**/*DTO.*",
                "**/config/*"
            ])
        }))
    }
}

Above, we use a closure to traverse the class directories and eliminate files that match a list of specified patterns. As a result, generating the report using ./gradlew jacocoTestReport or ./gradlew clean test will exclude all the specified classes and packages, as expected.

It's worth noting that the JaCoCo plugin is bound to the test phase here which runs all the tests prior to generating the reports.

4. Excluding With Custom Annotation

Starting from JaCoCo 0.8.2, we can exclude classes and methods by annotating them with a custom annotation with the following properties:

• The name of the annotation should include Generated.
• The retention policy of annotation should be runtime or class.

First, let's create our annotation:

@Documented
@Retention(RUNTIME)
@Target({TYPE, METHOD})
public @interface Generated {
}

Now we can annotate class(es) or method(s) that should be excluded from the coverage report.

Let's use this annotation at the class level first:

@Generated
public class Customer {
    // everything in this class will be excluded from jacoco report because of @Generated
}

Similarly, we can also apply this custom annotation to a specific method in a class:

public class CustomerService {
    @Generated
    public String getCustomerId() {
        // method excluded form coverage report
    }
    
    public String getCustomerName() {
        // method included in test coverage report
    }
}

5. Excluding Lombok Generated Code

Project Lombok is a popular library for greatly reducing boilerplate and repetitive code in Java projects.

Lastly, let's see how to exclude all Lombok-generated bytecode by adding a property to lombok.config file in our project's root directory:

lombok.addLombokGeneratedAnnotation = true

Basically, this property adds the lombok.@Generated annotation to the relevant methods, classes, and fields of all classes annotated with Lombok annotations e.g. the Product class. As a result, JaCoCo then ignores all the constructs annotated with this annotation and they're not shown in the reports.

Finally, we can see the report after applying all the exclusion techniques shown above:

6. Conclusion

In this article, we looked at various ways of specifying exclusions from the JaCoCo test report.

Initially, we excluded several files and packages using naming patterns in the plugin configuration. Then, we saw how to use @Generated to exclude certain classes as well as methods. Finally, we looked at how to exclude all the Lombok-generated code from the test coverage report using a config file.

As always, the Maven source code and Gradle source code are available over on Github.