Pour démarrer sur le sujet, vous avez suivi les étapes écrites sur mon post, comme je l’ai fait lors de ma présentation. C’est bien joli tout ça, mais dans la vraie vie réelle, vous n’avez pas un module Maven dédié au code JavaScript. Votre code JavaScript est (bêtement) dans votre application web ! Du coup, vous vous posez des questions sur la façon de procéder, en particulier concernant les analyses Sonar…

Allez zou, suivez le guide !

Zou, créons un projet

Lors de ma présentation, j’ai utilisé l’archetype Maven de.akquinet.javascript.archetypes:javascript-quickstart, qui crée un squelette d’application contenant juste du JavaScript.
Cette fois-ci, on va partir d’un projet web classique dans lequel on incluera notre code JavaScript. Donc quelque chose de plus proche que ce que vous avez sur votre projet !

Je pars donc avec l’archetype org.codehaus.mojo.archetypes:webapp-javaee6 pour avoir un squelette d’application web. Il s’agit là de votre propre projet web… De mon côté, j’y ajoute une petite classe Java, ainsi qu’une class de test JUnit pour le fun.

Désormais, on peut lancer une première analyse Sonar, avec la commande mvn clean install sonar:sonar.

Jusqu'ici, tout va bien !

Maintenant, je rajoute mon code JavaScript (les fichiers underscore.js et undescore-test.js). Je les positionne respectivement dans les répertoires src/main/javascript et src/test/javascript. Il est possible d’adapter ces répertoires, bien entendu !
On ajoute le fichier de configuration de jsTestDriver.conf qui va nous permettre de lancer nos tests JavaScript de Jasmine. On ajoute aussi dans un coin (le répertoire lib/ disons) :

• le fichier jasmine.js ;
• le fichier jasmineAdapter.js (pour lancer les tests JavaScript écrits en Jasmine avec js-test-driver) ;
• la librairie coverage-1.3.4.b.jar, qui est le plugin de calcul de couverture du code JavaScript pour js-test-driver.

Au final, la structure de mon projet a la tête suivante :

chouchoutage (oui, c'est le nom pourri de mon projet)
  + pom.xml
  ` src
      + lib
      |   ` coverage-1.3.4.b.jar
      |   ` jasmine.js
      |   ` jasmineAdapter.js
      + main
      |   + java
      |   |   ` ze-code-java
      |   ` javascript
      |       ` underscore.js
      + test
      |   + java
      |   |   ` test-unitaires
      |   ` javascript
      |       ` underscore-test.js
      ` webapp
          ` toute-la-partie-web

Si vous souhaitez plus d’informations sur cette étape (comme le contenu du fichier jsTestDriver.conf par exemple), allez jeter un oeil sur mon post décrivant ma session Devoxx.

Voilà, on arrive à quelque chose qui ressemble en gros à votre projet. Maintenant, on va voir comment on va pouvoir exécuter nos codes JavaScript, et en faire l’analyse Sonar.

Ne tombons pas dans les poms !

Attaquons nous au problème principal : la modification du pom. Nous allons d’abord l’adapter pour exécuter nos tests JavaScript. Nous verrons ensuite pour l’analyse Sonar…

Ajoutons d’abord la dépendance suivante :

    <dependency>
        <groupId>com.googlecode.jstd-maven-plugin</groupId>
        <artifactId>jstd-maven-plugin</artifactId>
        <version>1.3.2.5</version>
        <scope>test</scope>
    </dependency>

On ajoute ensuite le plugin de jstd-maven-plugin :

    <plugin>
        <groupId>com.googlecode.jstd-maven-plugin</groupId>
        <artifactId>jstd-maven-plugin</artifactId>
        <version>1.3.2.5</version>
        <configuration>
            <port>9876</port>
            <!-- A adapter ! -->
            <browser>/Applications/Firefox.app/Contents/MacOS/firefox-bin</browser>
            <tests>all</tests>
            <config>jsTestDriver.conf</config>
            <testOutput>target/jstestdriver</testOutput>
        </configuration>
        <executions>
            <execution>
                <id>run-tests</id>
                <goals>
                    <goal>test</goal>
                </goals>
            </execution>
        </executions>
    </plugin>

Dernier point, nous ajoutons le repository contenant les plugins sus-cités :

    <repositories>
          <repository>
              <id>jstd-maven-plugin google code repo</id>
              <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
          </repository>
    </repositories>
    <pluginRepositories>
          <pluginRepository>
              <id>jstd-maven-plugin google code repo</id>
              <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
          </pluginRepository>
    </pluginRepositories>

Voilà, nous pouvons vérifier si cela fonctionne. La commande mvn clean install va nous le dire :

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.linsolas.WorldTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- jstd-maven-plugin:1.3.2.5:test (run-tests) @ chouchoutage ---

-------------------------------------------
 J S  T E S T  D R I V E R
-------------------------------------------

Firefox: Runner reset.
................
Total 16 tests (Passed: 16; Fails: 0; Errors: 0) (10,00 ms)
  Firefox 9.0.1 Mac OS: Run 16 tests (Passed: 16; Fails: 0; Errors 0) (10,00 ms)

C’est plutôt une bonne nouvelle ça ! Surefire a lancé mon test JUnit (fr.linsolas.WorldTest), puis, dans un second temps, a exécuté les tests de js-test-driver.

Plongeons dans l’analyse Sonar

Et bien voilà, il ne nous reste plus qu’à exécuter une analyse Sonar et le tour est joué… Mais ce n’est pas si simple en fait !
Sonar permet bien d’analyser un projet Java, il permet d’analyser également un projet JavaScript, mais hélas pas en même temps !
Nous allons devoir donc lancer deux analyses Sonar pour arriver à nos fins.

Etant donné que nous ne voulons pouvoir lancer avec le même pom.xml l’analyse Sonar pour le code Java et l’analyse Sonar pour le code JavaScript, nous allons créer un profil Maven qui sera dédié à l’analyse JavaScript :

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <sonar.language>js</sonar.language>
                <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
            </properties>
        </profile>
    </profiles>

Voyons voir si cela fonctionne. Lançons une première analyse avec mvn clean install sonar:sonar. En exécutant cette commande, l’analyse Sonar ne montre aucune différence avec celle réalisée plus tôt. Normal, me direz-vous, on reste sur l’analyse Java.
Lançant maintenant la même commande, mais en activant le profile js : mvn -Pjs clean install sonar:sonar. Le résultat n’est pas celui attendu :

Ooooups

Houlà, mais on a tout cassé ! On n’obtient plus aucun chiffre, ni rien Le problème vient simplement du fait que le plugin JavaScript pour Sonar va chercher les sources dans le répertoire src/main/java au lieu de src/main/javascript.
Il faut donc lui spécifier ce nouveau répertoire. On va donc spécifier un sourceDirectory dans notre profile js. Du moins on aimerait bien, car hélas Maven n’autorise pas que l’on redéfinisse ce répertoire dans un profil ! C’est étrange, mais c’est comme ça. Enfin pas tant que ça, car Maven – par défaut – n’accepte qu’un seul chemin de sources. Comme plusieurs profiles peuvent être actifs en même temps, on pourrait bidouiller les profiles pour avoir ainsi plusieurs répertoires de sources. On s’égare un peu là…
Nous pourrions passer par le plugin build-helper qui permet de spécifier plusieurs répertoires de sources. Je n’en ferais rien, je vais « simplement » fourvoyer Maven en jouant avec les propriétés :

    <properties>
        <source.dir>src/main/java</source.dir>
        <test.source.dir>src/test/java</test.source.dir>
    </properties>

    <build>
        <sourceDirectory>${source.dir}</sourceDirectory>
        <testSourceDirectory>${test.source.dir}</testSourceDirectory>
        ...
    </build>

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <source.dir>src/main/javascript</source.dir>
                <test.source.dir>src/test/javascript</test.source.dir>
                ...

Voilà, Maven n’y voit que du feu, et moi j’ai réussi à me débrouiller (à bidouiller disons plutôt).

Alors, que donne l’analyse Sonar maintenant ?

Voilà qui est mieux !

OUI ! Enfin, nous réussissons à obtenir notre belle analyse du code JavaScript par Sonar !

Et voilà, c’est fini.
Vraiment ? Non !
Un dernier souci se pose : si je lance l’analyse Java, j’ai un beau rapport Sonar. Mais dès que je lance l’analyse JavaScript, mon rapport JavaScript efface celui de Java !
Il faut donc trouver un moyen de faire cohabiter les deux. Je propose simplement de profiter de l’option sonar.branch pour différencier les deux projets. On ajoute donc dans le profil js :

    <profiles>
        <profile>
            <id>js</id>
            <properties>
                <sonar.branch>javascript</sonar.branch>
                ...

Cette fois-ci, on relance les deux analyses : mvn clean install sonar:sonar puis mvn -Pjs clean install sonar:sonar.
Une fois les deux commandes terminées, nous nous retrouvons avec non plus un mais deux projets Sonar :

Les deux font la paire

Chacun de ces projets est adapté à son langage, le premier pour Java, le second pour JavaScript.

Et voilà, c’est fini.
Vraiment ? Cette fois, oui

N’hésitez pas à faire part, dans les commentaires, de vos propres expériences, ou propositions d’améliorations !

Start Slide Show with PicLens Lite

Le but de cette présentation est de montrer qu’il est aussi facile de tester et analyser son code JavaScript que son code Java. Les mêmes outils seront d’ailleurs utilisés, en particulier Maven, Jenkins et Sonar.

Avant toute chose, nous allons prendre underscore.js comme cobaye pour nos tests. Pour information, il s’agit d’une librairie proposant une soixantaine de fonctions JS permettant de faire de la programmation fonctionnelle.

Etape #1: Créer le projet

Mon choix, pour la première librairie de tests, c’est Jasmine. Il s’agit d’une librairie avec une communauté assez active, et disposant d’un certain nombre de supports : Java et Maven, .Net, Ruby, Node.js, etc.
Pour être plus précis, cette librairie va être surtout utilisée lorsque l’on souhaite faire du BDD (Behavior Driven Development). D’ailleurs, dans la terminologie de Jasmine, on ne parle pas de test, mais de spec.

Comme dit précédemment, Jasmine offre un support Maven. Pour ma présentation, j’opte pour la création d’un projet squelette, via un archetype Maven. Cela se fait via cette commande :

mvn archetype:generate
    -DarchetypeRepository=http://searls-maven-repository.googlecode.com/svn/trunk/snapshots
    -DarchetypeGroupId=com.github.searls
    -DarchetypeArtifactId=jasmine-archetype
    -DarchetypeVersion=1.1.0.1-SNAPSHOT
    -DgroupId=fr.devoxx
    -DartifactId=chouchoutez-javascript
    -Dversion=0.0.1-SNAPSHOT

Une fois ceci réalisé, nous obtenons un projet (que nous allons importer dans notre IDE préféré) ayant la structure suivante :

pom.xml
  ` src
     + main
     |  ` javascript
     |      ` quickstart.js
     ` test
        ` javascript
           ` quickstartTest.js

La partie intéressante dans le pom.xml est la déclaration du plugin Jasmine qui va permettre de lancer les tests via une commande Maven :

        <plugins>
            <plugin>
                <groupId>com.github.searls</groupId>
                <artifactId>jasmine-maven-plugin</artifactId>
                <version>1.0.1-beta-6</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>generateManualRunner</goal>
                            <goal>resources</goal>
                            <goal>testResources</goal>
                            <goal>test</goal>
                            <goal>preparePackage</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <jsSrcDir>src/main/javascript</jsSrcDir>
                    <jsTestSrcDir>src/test/javascript</jsTestSrcDir>
                </configuration>
            </plugin>

En lançant la commande mvn test, on voit que le test généré par défaut par l’archetype est lancé :

-------------------------------------------------------
 J A S M I N E   T E S T S
-------------------------------------------------------
[INFO]
describe The quickstart object
  it adds two numbers
[INFO]
Results:

1 specs, 0 failures

Etape #2 : Ecrire des tests

Je copie mon underscore.js dans le répertoire src/main/javascript, et nous allons le tester…
Jasmine propose une écriture assez intuitive des tests, assez proche de fest-assert. En voici un premier exemple :

describe("Mon premier test", function() {
    it("should be 42", function() {
        var resultat = _.max([1, 2, 3, 42]);
        expect(resultat).toBe(42);
    };
};

Avec Jasmine, on crée une suite de tests en utilisant le mot describe, suivi de son descriptif. Ensuite, on y ajoute une série de tests (voire on imbrique de nouvelles suites), chaque test (ou plus exactement chaque spec) étant défini par le mot clé it. On écrit le code du test, puis au moment de vérifier (i.e. de réaliser les assert), on va simplement utiliser expect suivi d’un matcher (ici toBe). Plusieurs autres matchers existent (toEqual, toBeNull, toBeGreaterThan, toContain, toBeUndefined).

A nouveau, je vérifie mes tests avec la commande Maven mvn clean test.

Voici mon fichier de tests final de la librairie underscore.js :

describe("Mon premier test", function() {

  it("should be 42", function() {
    var max = _.max([1, 2, 42]);
    expect(max).toBe(42);
  });

});

describe("Test d'underscore", function() {

    var myarray;

    beforeEach(function() {
        myarray = [1, 2, 3];
    });

    it("should return 42 when asked for last item", function() {
        var res = _.last([1,2,3,42]);
        expect(res).toBe(42);
    });

    it("be true", function() {
        var res = _.first([1, 2, 3]);
        expect(res == 1).toBeTruthy();
    });

    it("should be greater than 2", function() {
        expect(3).toBeGreaterThan(2);
    });

    it("should contains 2", function() {
        expect([1, 2, 3]).toContain(2);
    });

    it("should have size of 3", function() {
        expect(myarray.length).toBe(3);
    });

    it("should not be 1", function() {
        var res = _.max([1, 2]);
        expect(res).not.toBe(1);
    })

});

describe("test with spy", function() {

    it("should spy on last", function() {
        spyOn(_, 'last');
        var res = _.last([1, 2, 3]);
        expect(_.last).toHaveBeenCalled();
        expect(res).toBeUndefined();
    });

});

Vous remarquerez qu’à l’instar d’un @Before de JUnit, Jasmine offre la même possibilité avec beforeEach.
De plus, Jasmine offre aussi des fonctionnalités d’espionnage.

Etape #3 : Analyser son code

Pour analyser le code JavaScript, nous allons utiliser le merveilleux outil qu’est Sonar ! Il nous faut simplement y ajouter le plugin pour le support du langage JavaScript, qui se trouve ici.

Dans notre pom.xml, nous devons ajouter ces quelques lignes, pour spécifier que le projet est de langage JavaScript, et indiquer la localisation de nos sources (et celles des tests) :

    <properties>
        <sonar.language>js</sonar.language>
        <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    </properties>

    <build>
        <sourceDirectory>src/main/javascript</sourceDirectory>
        <testSourceDirectory>src/test/javascript</testSourceDirectory>

Il suffit désormais de lancer la commande mvn sonar:sonar pour réaliser l’analyse complète, puis de se rendre sur son serveur Sonar pour en lire les résultats !

Tout n’est pas encore parfait, car nous ne disposons d’aucune information propres aux tests : pourcentage de réussite, taux de couverture du code, etc.

Etape #4 : Analyse de la couverture

Le plugin JavaScript pour Sonar sait lire les résultats des tests exécutés par js-test-driver, une autre librairie de tests JavaScript, plus orientée TDD (Tests Driven Development, ou Développement piloté par les tests). Cette librairie apporte une syntaxe très proche de JUnit, en particulier concernant les assertions. En voici un exemple :

GreeterTest = TestCase("GreeterTest");

GreeterTest.prototype.testGreet = function() {
    var greeter = new myapp.Greeter();
    assertEquals("Hello World!", greeter.greet("World"));
};

Bon. Mais il faut tout réécrire, et perdre ce que l’on a fait avec Jasmine du coup ? Heureusement non ! Il existe en effet un adaptateur pour exécuter des tests Jasmine via js-test-driver.
Bien entendu, nous aurions pu partir dès le début avec la librairie js-test-driver, et oublier Jasmine, mais ça n’aurait pas été fun !

Donc pour faire marcher tout cela, il faut tout d’abord copier dans un répertoire lib/ les fichiers suivants :

• jasmine.js (auparavant, il était chargé via le plugin Maven, que nous n’allons plus utiliser.
• JasmineAdapter.js, le fameux adaptateur.

Puis, je crée un fichier jsTestDriver.conf à la racine du projet qui contient la configuration pour js-test-driver :

server: http://localhost:9876

load:
  - "lib/jasmine.js"
  - "lib/JasmineAdapter.js"
  - "src/main/javascript/*.js"
  - "src/test/javascript/*.js"

Ici c’est très simple, on indique le port où tournera le serveur js-test-driver, ainsi que les librairies à charger…

Dernière étape : modifier le pom.xml. D’abord, y supprimer les références au plugin Jasmine, devenu obsolète. Ensuite, ajouter ceci pour la dépendance vers le plugin Maven de js-test-driver :

    <dependencies>
        <dependency>
            <groupId>com.googlecode.jstd-maven-plugin</groupId>
            <artifactId>jstd-maven-plugin</artifactId>
            <version>1.3.2.5</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

Puis je configure le plugin comme ceci :

    <build>
        ...
        <plugins>
            <plugin>
                <groupId>com.googlecode.jstd-maven-plugin</groupId>
                <artifactId>jstd-maven-plugin</artifactId>
                <configuration>
                    <port>9876</port>
                    <browser>/Applications/Firefox.app/Contents/MacOS/firefox-bin</browser>
                    <tests>all</tests>
                    <config>jsTestDriver.conf</config>
                    <testOutput>target/jstestdriver</testOutput>
                </configuration>
                <executions>
                    <execution>
                        <id>run-tests</id>
                        <goals>
                            <goal>test</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

On notera que certaines informations du fichier jsTestDriver.conf (comme le port du serveur) sont reprises ici. On spécifie aussi le chemin vers le navigateur utilisé par js-test-driver pour exécuter ses tests (chose inutile avec Jasmine, car ce dernier ne nécessite même pas de DOM pour exécuter les tests !).
Dernier point : j’ajoute le repository où se trouve le plugin js-test-driver :

  <repositories>
        <repository>
            <id>jstd-maven-plugin google code repo</id>
            <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
        </repository>
  </repositories>
  <pluginRepositories>
        <pluginRepository>
            <id>jstd-maven-plugin google code repo</id>
            <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url>
        </pluginRepository>
  </pluginRepositories>

Maintenant, pour voir si tout s’est bien passé, je vérifie que l’exécution des tests se réalise bien. J’exécute donc de nouveau la commande Maven mvn clean test :

-------------------------------------------
 J S  T E S T  D R I V E R
-------------------------------------------

Firefox: Runner reset.
..................
Total 18 tests (Passed: 18; Fails: 0; Errors: 0) (9,00 ms)
  Firefox 9.0.1 Mac OS: Run 18 tests (Passed: 18; Fails: 0; Errors 0) (9,00 ms)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Bravo ! C’est presque gagné ! Il ne nous reste plus qu’à pouvoir mesurer la couverture des tests. Rien de plus simple à ce stade : il suffit d’éditer le fichier jsTestDriver.conf et d’y ajouter les 4 lignes suivantes :

plugin:
  - name: "coverage"
    jar: "lib/coverage-1.3.4.b.jar"
    module: "com.google.jstestdriver.coverage.CoverageModule"

Je relance mvn clean package sonar:sonar, et l’analyse contient désormais les résultats des tests, mais aussi la couverture du code !

Etape #5 : Intégration continue

Lors de la présentation, j’ai manqué de temps et ai dû passé cette étape. Mais ici, rien de magique ni d’extraordinaire. En effet, comme depuis le début j’utilise des commandes Maven, les faire jouer par un serveur d’intégration continue est d’une simplicité enfantine. Je vous laisse donc le soin de jouer avec Jenkins ou tout autre serveur…

Conclusion

J’ai montré en une demi-heure environ qu’il était très simple de tester son code JavaScript, de l’analyser. Les mêmes outils sont d’ailleurs mis en oeuvre que pour le langage Java : Maven, Sonar et Jenkins.

Bref, il ne reste plus qu’à s’y mettre

Références

• Projet sur GitHub
• Slides sur Slideshare
• Abstract sur le site de DevoxxFR
• Vidéo Parleys (à venir)

Start Slide Show with PicLens Lite

Contexte

Dans mon exemple, je me baserais sur les outils suivants : Sonar 2.8, Maven 2.2.1, Java 1.6.

Au sein de l’un de mes projets, je dispose de quelques rares tests unitaires, qui couvre environ 7% de l’application. C’est peu. Très peu. Trop peu même.
Mais nous avons également des tests d’intégration.
En gros, ces tests d’intégration vont exécuter un jeu d’environ 300 fichiers d’entrée, qui seront ensuite analysés par mon application.

Mon but est donc de connaître, en plus de ma couverture de test par les tests JUnit, la couverture du code exécuté par mes tests d’intégration.

La structure de mon projet ressemble en gros à ceci :

mon-projet
  +- pom.xml (ce pom-là n'est qu'un pom d'aggrégation)
  +- parent
  |   +- pom.xml (c'est le vrai parent de tous les autres modules)
  +- module-1
  |   +- pom.xml
  +- module-2
  |   +- pom.xml
  +- ...
  +- module-tests
      +- pom.xml
      +- src/test/java/
          +- foo/bar/IntegrationTestsRunner.java

module-tests est un module ne contenant que quelques classes de tests, en particulier IntegrationTestsRunner.java dont le but est d’aller lire mes fichiers de tests, et les exécuter.

Afin de ne pas lancer ces tests d’intégration à chaque build, nous définissons un profil Maven dans le pom.xml de module-tests, comme suit :

    <profiles>
        <profile>
            <id>run-it</id>
            <activation>
                <property>
                    <name>runIT</name>
                    <value>true</value>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <includes>
                                <include>**/IntegrationTestRunner.java</include>
                            </includes>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Ce profil sera activé soit en ajoutant -DrunIT=true soit -Prun-it dans la ligne de commande Maven.

Avec une méthode « traditionnelle », c’est-à-dire l’exécution de tests unitaires via Surefire, aucune couverture de code ne sera détectée, car le code exécuté par les tests d’intégration l’est sur les autres modules du projet. Or Cobertura ne va instrumentaliser que les classes du module courant et non les dépendances (i.e. module-1, module-2, etc.).

Mise en place de JaCoCo

Pour résoudre mon problème, je vais faire appel à JaCoCo, un outil de couverture de test plus performant que Cobertura. Son principal avantage est de pouvoir instrumentaliser les classes au runtime. Dans mon cas présent, JaCoCo va donc pouvoir vérifier la couverture du code sur les différents modules au moment où l’on exécute module-tests.

Avant toute chose, il va nous falloir configurer un peu notre environnement :

• Installer le plugin JaCoCo pour Sonar (à copier dans le répertoire extensions/plugins de son installation Sonar).
• Une fois Sonar redémarré, penser à ajouter dans le dashboard le widget IT Coverage Widget (il faudra sans doute pour cela être connecté en tant qu’administrateur).
• Télécharger l’agent JaCoCo. Pour cela, il faut récupérer le ZIP de JaCoCo ici, l’agent se trouvant alors dans lib/jacocoagent.jar.

Maintenant que ceci est en place, nous allons devoir indiquer à Surefire d’utiliser un agent Java spécifique (l’agent JaCoCo).
Etant donné que nous n’avons besoin de cet agent qu’au moment de l’exécution des tests d’intégration, nous le définirons que pour le profil run-it.
Au sein du pom.xml parent, j’ai donc ajouté :

    <profiles>
        <!-- Profile used to run Integration Tests. In such case, we add the Java agent for JaCoCo... -->
        <profile>
            <id>run-it</id>
            <activation>
                <property>
                    <name>runIT</name>
                    <value>true</value>
                </property>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                            <argLine>-javaagent:${jacoco.agent.path}=destfile=${jacoco.file.path}</argLine>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

J’ai défini mon profil deux fois, dans le pom.xml parent et dans celui de module-tests. Nous aurions pu tout mettre dans le parent.

Execution

Nous allons avoir besoin d’exécuter maintenant deux commandes Maven :

• mvn clean install -DrunIT=true -Djacoco.agent.path=C:\dev\jacocoagent.jar -Djacoco.file.path=C:\dev\monprojet\jacoco.exec
• mvn -Dsonar.jacoco.itReportPath=C:\dev\monprojet\jacoco.exec sonar:sonar

La première ligne va activer le profil run-it, ce qui aura pour conséquence de lancer le tests d’intégration.
On y définit les deux paramètres (jacoco.agent.path et jacoco.file.path) qui seront passés à Surefire pour définir un agent Java.

La seconde ligne va simplement exécuter l’analyse Sonar sur mon projet, mais en définissant le paramètre sonar.jacoco.itReportPath (généré lors de la première commande), cette analyse comprendra également la couverture des tests d’intégration.

Une fois les deux commandes exécutées, il suffit de se rendre sur son serveur Sonar pour apprécier cette nouvelle mesure de couverture de code !

Comme le montre les captures d’écran sur le post du blog de Sonar à ce sujet, il est possible, à l’instar de la couverture de code, de visualiser la couverture de code de tests d’intégration directement dans la fenêtre de visualisation du code source d’une classe.

Start Slide Show with PicLens Lite