dev 5260 Views

Générer un coverage prenant en compte les tests unitaires et d’intégration dans un même rapport avec JaCoCo

28 mai 2023

Sommaire

Introduction

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.

Installer JaCoCo

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>

Générer un fichier d’exécution pour les tests unitaires

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.

Générer un fichier d’exécution pour les tests d’intégration

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>

Fusionner les rapports

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.

Code final

<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>

https://github.com/maximedezette/globalDependenciesDashboardBack/commit/e44ff212d76aeb5bf0ac6ca063b9f32e1d36756b

Written By

Maxime

Comments :

jp 30 novembre 2024, 0 h 54 min

Y’a moyen d’avoir la meme chose pour un projet multimodules ? (module1, module2)

Répondre
- Maxime 30 novembre 2024, 20 h 05 min
  
  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.
  
  Répondre

Laisser un commentaire Annuler la réponse

Ne plus perdre de temps en conflits lorsqu’on a des branches qui partent d’autres branches de travail grâce à git rebase –onto

Il arrive que la code review nous empêche de merge nos PR assez vite et qu’on se retrouve à tirer une branche d’une branche de travail pour avancer 😔 Une fois la première PR squash et merge, la PR issue de la seconde branche se retrouve avec des conflits 💥 Si vous avez déjà vécu cette situation, il y a de bonnes chances que vous ayez cherry-pick vos commits de travail sur une...

Maxime

31 mars 2025

Des tests paramétrés avec Nunit

Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests. On va voir comme...

Maxime

15 mars 2025

Tester facilement les dates grâce à TimeProvider en .Net – exemple avec un scénario Reqnroll

Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut ! En deux mots, TimeProvider est une...

Maxime

25 janvier 2025

Une gestion d’erreur de son API .Net automatique via ses exceptions

La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir. On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...

Maxime

21 décembre 2024