Sommaire
JaCoCo est un outil très connu dans le monde Java qui permet de générer des rapports de code coverage au format xml et html.
L’intérêt sera souvent de donner le rapport au format xml à d’autres outils (Codecov ou Sonar par exemple) pour suivre le code coverage de votre projet.
Nous allons voir pas à pas comment configurer Jacoco pour qu’il génère un rapport prenant en compte les tests unitaires et les tests d’intégration sur un même rapport.
Dans votre pom.xml, rajoutez les lignes suivantes
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.9</version>
</plugin>
</plugins>
</build>Les fichiers .exec sont des fichiers générés par JaCoCo comprenant les données d’exécution. C’est sur la base de ces fichiers que les rapports sont générés.
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.9</version>
<executions>
<execution>
<id>pre-unit-tests</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>Ici on dit simplement à Jacoco ‘’prépare une propriété qui va référencer le runtime JaCoCo qui sera passé lors de l’exécution des TU et génère un rapport après l’exécution des tests unitaires.
Ce sera exactement comme pour les tests unitaires. On va commander l’exécution de:
<execution>
<id>pre-integration-tests</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>post-integration-tests</id>
<phase>post-integration-test</phase>
<goals>
<goal>report-integration</goal>
</goals>
</execution>La seule nuance ici c’est que des valeurs par défauts seront transmises. A ce stade on a la configuration suivante:
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.9</version>
<executions>
<execution>
<id>pre-unit-tests</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>pre-integration-tests</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>post-integration-tests</id>
<phase>post-integration-test</phase>
<goals>
<goal>report-integration</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
L’idée va être de prendre les deux fichiers .exec générés par JaCoCo lors des étapes précédentes et de les fusionner dans un seul fichier.
Une fois fait, il suffit de dire à JaCoCo de se baser sur le fichier .exec final pour générer un rapport comprenant le coverage des tests unitaires et de ceux des tests d’intégration.
<execution>
<id>merge</id>
<phase>verify</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<fileSets>
<fileSet implementation="org.apache.maven.shared.model.fileset.FileSet">
<directory>${project.basedir}</directory>
<includes>
<include>**/*.exec</include>
</includes>
</fileSet>
</fileSets>
<destFile>target/jacoco/allTest.exec</destFile>
</configuration>
</execution>
<execution>
<id>post-merge-report</id>
<phase>verify</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>target/jacoco/allTest.exec</dataFile>
<outputDirectory>target/jacoco/</outputDirectory>
</configuration>
</execution>
Astuce: si vous voulez que vos tests Cucumber soient pris en compte pour le code coverage généré par JaCoCo, il suffit de suffixer le nom de votre Runner par IT afin qu’ils soient joués au
mvn verify.
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.9</version>
<executions>
<execution>
<id>pre-unit-tests</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>pre-integration-tests</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>post-integration-tests</id>
<phase>post-integration-test</phase>
<goals>
<goal>report-integration</goal>
</goals>
</execution>
<execution>
<id>merge</id>
<phase>verify</phase>
<goals>
<goal>merge</goal>
</goals>
<configuration>
<fileSets>
<fileSet implementation="org.apache.maven.shared.model.fileset.FileSet">
<directory>${project.basedir}</directory>
<includes>
<include>**/*.exec</include>
</includes>
</fileSet>
</fileSets>
<destFile>target/jacoco/allTest.exec</destFile>
</configuration>
</execution>
<execution>
<id>post-merge-report</id>
<phase>verify</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>target/jacoco/allTest.exec</dataFile>
<outputDirectory>target/jacoco/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Written By
On va voir comment avoir en quelques minutes des assertions qui vont vérifier les endpoints de notre API avec des scénarios de ce genre: Feature: Create a new account As a visitor, I can create an account to access the game Scenario: A visitor creates an account When I fill the login form with | email | password | | [email protected] | Jh0...
Depuis .NET 9, le le support d’OpenAPI est directement inclus dans .NET et ne passe plus par les librairies Swagger par défaut (plus d’info sur ce choix ici si jamais ça vous intéresse). De façons simplifiée, la librairie Swashbuckle.AspNetCore.Sw...
Description du problème Par défaut, il n’est pas autorisé de faire des requêtes entre une application qui est dans un domaine A vers une autre qui serait dans un domaine B (pour des raisons de sécurité, il y a plus de détails dans les sources). S...
On va créer pas-à-pas un raccourci qui nous permettra de générer un IBAN et de l’insérer à l’endroit où se trouve notre curseur. Si vous n’avez pas fait le setup pour développer un plugin Jetbrains, je vous invite à lire notre article sur le sujet. ...
Y’a moyen d’avoir la meme chose pour un projet multimodules ? (module1, module2)
Oui aucun problème: en mergeant les .exec générés dans le projet, on va logiquement prendre ceux générés dans les différents modules ce qui va aggréger leur coverage et donner un coverage global dans le projet.