测量你的测试的覆盖率
Learn how to measure the test coverage of your application. This guide covers:
-
Measuring the coverage of your Unit Tests
-
Measuring the coverage of your Integration Tests
-
Separating the execution of your Unit Tests and Integration Tests
-
Consolidating the coverage for all your tests
Please note that code coverage is not supported in native mode.
1. 先决条件
完成这个指南,你需要:
-
大概15分钟
-
编辑器
-
JDK 17+ installed with
JAVA_HOME
configured appropriately -
Apache Maven 3.9.9
-
如果你愿意的话,还可以选择使用Quarkus CLI
-
如果你想构建原生可执行程序,可以选择安装Mandrel或者GraalVM,并正确配置(或者使用Docker在容器中进行构建)
-
Having completed the Testing your application guide
2. 应用结构
The application built in this guide is just a Jakarta REST endpoint (hello world) that relies on dependency injection to use a service.
The service will be tested with JUnit 5 and the endpoint will be annotated via a @QuarkusTest
annotation.
3. 解决方案
We recommend that you follow the instructions in the next sections and create the application step by step. However, you can go right to the completed example.
Clone the Git repository: git clone https://github.com/quarkusio/quarkus-quickstarts.git
, or download an archive.
The solution is located in the tests-with-coverage-quickstart
directory.
4. Starting from a simple project and two tests
Let’s start from an empty application created with the Quarkus Maven plugin:
For Windows users:
-
If using cmd, (don’t use backward slash
\
and put everything on the same line) -
If using Powershell, wrap
-D
parameters in double quotes e.g."-DprojectArtifactId=tests-with-coverage-quickstart"
Now we’ll be adding all the elements necessary to have an application that is properly covered with tests.
First, a Jakarta REST resource serving a hello endpoint:
package org.acme.testcoverage;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
@Path("/hello")
public class GreetingResource {
private final GreetingService service;
@Inject
public GreetingResource(GreetingService service) {
this.service = service;
}
@GET
@Produces(MediaType.TEXT_PLAIN)
@Path("/greeting/{name}")
public String greeting(String name) {
return service.greeting(name);
}
@GET
@Produces(MediaType.TEXT_PLAIN)
public String hello() {
return "hello";
}
}
This endpoint uses a greeting service:
package org.acme.testcoverage;
import jakarta.enterprise.context.ApplicationScoped;
@ApplicationScoped
public class GreetingService {
public String greeting(String name) {
return "hello " + name;
}
}
The project will also need a test:
package org.acme.testcoverage;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.Tag;
import java.util.UUID;
import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;
@QuarkusTest
public class GreetingResourceTest {
@Test
public void testHelloEndpoint() {
given()
.when().get("/hello")
.then()
.statusCode(200)
.body(is("hello"));
}
@Test
public void testGreetingEndpoint() {
String uuid = UUID.randomUUID().toString();
given()
.pathParam("name", uuid)
.when().get("/hello/greeting/{name}")
.then()
.statusCode(200)
.body(is("hello " + uuid));
}
}
5. Setting up JaCoCo
Now we need to add JaCoCo to our project. To do this we need to add the following to the build file:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jacoco</artifactId>
<scope>test</scope>
</dependency>
testImplementation("io.quarkus:quarkus-jacoco")
This Quarkus extension takes care of everything that would usually be done via the JaCoCo Maven plugin, so no additional config is required.
Using both the extension and the plugin requires special configuration, if you add both you will get lots of errors about classes already being instrumented. The configuration needed is detailed below. |
6. Working with multi-module projects
Up until 3.2
, data-file
and report-location
were always relative to the module’s build output directory, which prevented from
working with multi-module projects where you want to aggregate all coverages into a single parent directory. Starting in 3.3
,
specifying a data-file
or report-location
will assume the path as is. Here is an example on how to set up the surefire
plugin:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<quarkus.jacoco.data-file>${maven.multiModuleProjectDirectory}/target/jacoco.exec</quarkus.jacoco.data-file>
<quarkus.jacoco.reuse-data-file>true</quarkus.jacoco.reuse-data-file>
<quarkus.jacoco.report-location>${maven.multiModuleProjectDirectory}/target/coverage</quarkus.jacoco.report-location>
</systemPropertyVariables>
</configuration>
</plugin
If you need to configure the argLine property of the Surefire plugin (e.g. for setting memory parameters), you need to use Maven late property evaluation, otherwise the Jacoco agent will not be correctly added, and regular JUnit tests and Quarkus ComponentTest will not get covered. Example: <argLine>@{argLine} -your -extra -arguments</argLine> .
|
7. Running the tests with coverage
Run mvn verify
, the tests will be run and the results will end up in target/jacoco-reports
. This is all that is needed,
the quarkus-jacoco
extension allows JaCoCo to just work out of the box.
There are some config options that affect this:
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Configuration property |
类型 |
默认 |
---|---|---|
Whether or not the jacoco extension is enabled. Environment variable: Show more |
boolean |
|
The jacoco data file. The path can be relative (to the module) or absolute. Environment variable: Show more |
string |
|
Whether to reuse ( Environment variable: Show more |
boolean |
|
If Quarkus should generate the Jacoco report Environment variable: Show more |
boolean |
|
Encoding of the generated reports. Environment variable: Show more |
string |
|
Name of the root node HTML report pages. Environment variable: Show more |
string |
|
Footer text used in HTML report pages. Environment variable: Show more |
string |
|
Encoding of the source files. Environment variable: Show more |
string |
|
A list of class files to include in the report. May use wildcard characters (* and ?). When not specified everything will be included. For instance:
Environment variable: Show more |
list of string |
|
A list of class files to exclude from the report. May use wildcard characters (* and ?). When not specified nothing will be excluded. For instance:
Environment variable: Show more |
list of string |
|
The location of the report files. The path can be relative (to the module) or absolute. Environment variable: Show more |
string |
|
When working with a multi-module project, then for code coverage to work properly, the upstream modules need to be properly indexed. |
8. Coverage for tests not using @QuarkusTest
The Quarkus automatic JaCoCo config will only work for tests that are annotated with @QuarkusTest
. If you want to check
the coverage of other tests as well then you will need to fall back to the JaCoCo maven plugin.
In addition to including the quarkus-jacoco
extension in your pom.xml
you will need the following config:
This config will only work if at least one @QuarkusTest is being run. If you are not using @QuarkusTest then
you can simply use the JaCoCo plugin in the standard manner with no additional config.
|
8.1. Coverage for Integration Tests
To get code coverage data from integration tests, the following requirements need to be met:
-
The built artifact is a jar (and not a container or native binary).
-
JaCoCo needs to be configured in your build tool.
-
The application must have been built with
quarkus.package.write-transformed-bytecode-to-build-output
set totrue
Setting quarkus.package.write-transformed-bytecode-to-build-output=true should be done with caution and only if subsequent builds are done in a clean environment - i.e. the build tool’s output directory has been completely cleaned.
|
In the pom.xml
, you can add the following plugin configuration for JaCoCo. This will append integration test data into the same destination file as unit tests,
re-build the JaCoCo report after the integration tests are complete, and thus produce a comprehensive code-coverage report.
<build>
...
<plugins>
...
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
... (1)
<execution>
<id>default-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<destFile>${project.build.directory}/jacoco-quarkus.exec</destFile>
<append>true</append>
</configuration>
</execution>
<execution>
<id>report</id>
<phase>post-integration-test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>${project.build.directory}/jacoco-quarkus.exec</dataFile>
<outputDirectory>${project.build.directory}/jacoco-report</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
1 | All executions should be in the same <plugin> definition so make sure you concatenate all of them. |
In order to run the integration tests as a jar with the JaCoCo agent, add the following to your pom.xml
.
<build>
...
<plugins>
...
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${surefire-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
<configuration>
<systemPropertyVariables>
<java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
<maven.home>${maven.home}</maven.home>
<quarkus.test.arg-line>${argLine}</quarkus.test.arg-line>
</systemPropertyVariables>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Sharing the same value for quarkus.test.arg-line might break integration test runs that test different types of Quarkus artifacts. In such cases, the use of Maven profiles is advised.
|