Le but de cette présentation est de montrer les atouts de la librairie de tests Java TestNG, en particulier face à l’omniprésent JUnit.
Il faut l’avouer, aujourd’hui JUnit a réussi à combler certaines de ses lacunes par rapport à TestNG. Je pense par exemple au groupage / catégorisation des tests (JUnit 4.8 a introduit un
@Category bancal, mais grandement aidé par Maven Surefire depuis sa version 2.11), aux tests paramétrés (annotation @Parameters de JUnit), etc.Toutefois, je reste convaincu de l’intérêt de TestNG sur JUnit. Mais j’aimerais connaitre ton opinion…
Bref, toi, lectrice, lecteur de mon blog, si tu fais partie d’une catégorie suivante :
- Tu utilises déjà TestNG
- Tu as utilisé TestNG par le passé
- Tu aimerais bien utiliser TestNG
- Tu t’intéresses à TestNG
alors ton avis m’intéresse ! Dis-moi quels sont les intérêts que tu lui trouves ? Pourquoi le préfères-tu à JUnit, ou au contraire pourquoi préfères-tu JUnit ? Que lui manque-t’il ? Bref, dis moi tout !
Merci.
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)
]]>
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.
]]>For some reasons, I wanted to categorize my JUnit tests, in order to run only a subset of them.
But this is not as simple as it seems…
Context
In one of my projects, I have many unit tests. It appears that many of them are not unit at all.
Some of them require a real Oracle connection, some others need to load a complex Spring context…
My goal is to split these tests into several categories.
To ease the explanations, I will only consider the two following categories: @FastTest and @SlowTest.
Possible solutions
JUnit introduced recently, in version 4.8, the @Category annotation (see the changelog and also an example here).
The principle is to annotate a class (or a method) with @Category, and then to define the category on which it belongs. For my needs, I could write:
// Interfaces that define my test categories
public interface FastTest { }
public interface SlowTest { }
@Category(SlowTest.class)
public class ASlowTest {
@Test
public void foo() { ... }
}
@Category(FastTest.class)
public class ARealUnitTest {
@Test
public void foo() { ... }
}
This seems pretty good. But if we go into the details, in order to run all the tests that belong to a specific category, I have to write:
@RunWith(Categories.class)
@IncludeCategory(FastTest.class)
@SuiteClasses( { ARealUnitTest.class, AnotherRealUnitTest.class })
public class FastTestsSuite { }
Here comes the problem: I have to create a Suite (using the annotation @SuiteClasses) to define the classes that should be executed.
That means I have to maintain a list of all the tests for a given Suite. The omissions are therefore likely to be frequent…
Not using JUnit Suite?
How to solve this problem? Here are some ideas:
- Write the JUnit
Suitemanually as I just explained before, but I may forget to maintain them… - Let a Maven plugin creates the
Suite. I wrote such a plugin some years ago, and I can reuse it now. However, I need to define when this plugin should be executed. Indeed, as the purpose of this plugin is to create or modify Java classes, I can’t run it automatically or anytime. Moreover, it is possible that some classes should not be included in these suites. So this solution will not be considered here. - Use specific patterns for the filenames of the test classes. For example, the fast tests will be named
**FastTest.java, while the other ones will be named**SlowTest.java. Then, I will configure Maven, and some profiles, to use the correct pattern regarding which kind of tests category I want to run. I will not consider this solution neither, as this may also lead to errors. - Use TestNG instead of JUnit. TestNG is another test framework, which provides some advanced features. One of them is the definition of
groupsthat would be perfect for our needs, especially since Surefire (the test plugin for Maven) natively supports them. This is maybe the best solution for our current concern, but I want to keep JUnit, so, again, I will ignore this idea. - Modify the Surefire plugin (or why not JUnit directly?) in order to manage the
@Categorywithout having to define aSuite. However, this is not a good idea to modify these libraries…
So none of these ideas seems to be helpful…
The last idea: Using JUnit Suite!
The solution I will explain now is based on JUnit Suite. However, these suites will define dynamically the test classes that should be run.
This Suite will look into the classpath for all the classes that are annotated with a particular annotation.
During my searches, I found a project called classpathSuite. One of the purpose of this project is to build a Suite by looking into the ClassPath for some specific classes. Exactly what I want to do!
Using this library, I write the following classes:
@RunWith(Categories.class)
@Categories.IncludeCategory(FastTest.class)
@Suite.SuiteClasses( { AllTests.class })
public class FastTestsSuite {
}
@RunWith(ClasspathSuite.class)
public class AllTests {
}
and classpathSuite will find all the classes in the ClassPath that belong to the category FastTest.
Nice! But this seems to work only when I run my tests in Eclipse, not in a Maven context Or did I miss something?
So I have to re-implement this feature, but that will work with Maven!
The solution
First step: I create two simple annotations, @FastTest and @SlowTest.
They will be used to annotate my JUnit test classes. Note that my solution will only allow you to categorize an entire class, not a method. These annotations will be a replacement for @Category(FastTest.class) and @Category(SlowTest.class).
Now, I create a utility class that will look into the classpath and find the list of classes that are annotated with a specific annotation (@FastTest or @SlowTest in my case) and that belong to a given package (this condition is not technically mandatory, it is just to limit the searches).
On the Java point of view, I get:
public final class ClasspathClassesFinder {
/**
* Get the list of classes of a given package name, and that are annotated by a given annotation.
*
* @param packageName The package name of the classes.
* @param testAnnotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
*/
public static Class<?>[] getSuiteClasses(String packageName, Class<? extends Annotation> testAnnotation) {
try {
return getClasses(packageName, testAnnotation);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
/**
* Get the list of classes of a given package name, and that are annotated by a given annotation.
*
* @param packageName The package name of the classes.
* @param annotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
* @throws ClassNotFoundException If something goes wrong...
* @throws IOException If something goes wrong...
*/
private static Class<?>[] getClasses(String packageName, Class<? extends Annotation> annotation) throws ClassNotFoundException, IOException {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
String path = packageName.replace('.', '/');
// Get classpath
Enumeration<URL> resources = classLoader.getResources(path);
List<File> dirs = new ArrayList<File>();
while (resources.hasMoreElements()) {
URL resource = resources.nextElement();
dirs.add(new File(resource.getFile()));
}
// For each classpath, get the classes.
ArrayList<Class<?>> classes = new ArrayList<Class<?>>();
for (File directory : dirs) {
classes.addAll(findClasses(directory, packageName, annotation));
}
return classes.toArray(new Class[classes.size()]);
}
/**
* Find classes, in a given directory (recursively), for a given package name, that are annotated by a given annotation.
*
* @param directory The directory where to look for.
* @param packageName The package name of the classes.
* @param annotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
* @throws ClassNotFoundException If something goes wrong...
*/
private static List<Class<?>> findClasses(File directory, String packageName, Class<? extends Annotation> annotation)
throws ClassNotFoundException {
List<Class<?>> classes = new ArrayList<Class<?>>();
if (!directory.exists()) {
return classes;
}
File[] files = directory.listFiles();
for (File file : files) {
if (file.isDirectory()) {
classes.addAll(findClasses(file, packageName + "." + file.getName(), annotation));
} else if (file.getName().endsWith(".class")) {
// We remove the .class at the end of the filename to get the class name...
Class<?> clazz = Class.forName(packageName + '.' + file.getName().substring(0, file.getName().length() - 6));
// Does the file is annotated with the given annotation?
if (clazz.getAnnotation(annotation) != null) {
classes.add(clazz);
}
}
}
return classes;
}
NB: I used the example given in this post to write this code.
Thus, the code ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class) will return an array of classes that belong to the package my.company and annotated with @FastTest.
The next step consists in building a Suite that will use my utility class to find all the fast tests:
public class FastTestsSuite extends org.junit.runners.Suite {
public FastTestsSuite(Class<?> clazz, RunnerBuilder builder) throws InitializationError {
this(builder, clazz, ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class));
}
public FastTestsSuite(RunnerBuilder builder, Class<?> clazz, Class<?>[] suiteClasses) throws InitializationError {
super(builder, clazz, suiteClasses);
}
}
Last class to write: the entry point for the Maven Surefire plugin (this class will only run @FastTest, so I will have to write the same class for @SlowTest):
@RunWith(FastTestsSuite.class)
public class RunAllFastTests {
}
Now, I just need to configure Maven in order to run « only » this test:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Run only tests annotated with @FastTest. -->
<includes>
<include>**/RunAllFastTests.java</include>
</includes>
...
</configuration>
</plugin>
Please note that if you are working on a project with multi-modules (this is my case), you will have to define this RunAllFastTests.java in each module.
Regarding the slow tests, I just have to define a Maven profile that will launch the RunAllSlowTests class, which calls the Suite SlowTestsSuite. This Suite will use the utility class to find all classes annotated with @SlowTest. My continuous integration server Hudson Jenkins will activate this profile during the nightly-builds.
Conclusion
Finally, this solution is not really complex, and when the mechanism is developed, you just have to annotate your JUnit test class with the adequate annotation. This is simple.
However, I am quite disappointed that JUnit, a widely used test framework, does not provide such a mechanism natively. I hope that it will change in the near future…
Feel free to post your comments if you think that my solution is not the best one to solve this kind of problem.
Sources
Jean-Philippe Briend suggested me on Twitter to provide the sources of the classes. Here they are:
ZIPThis project requires Maven 2 or 3, Java 1.6 and JUnit 4.8.1.
In addition to all the classes required for the mechanism, this project contains three basic unit tests:
OneFastTest, annotated with@FastTest;OneSlowTest, annotated with@SlowTest;TestWithoutAnnotation, without any annotation. As this test should not be executed, it contains a method that will call the JUnitfail()method. Thus, if this class is executed, the test will fail.
If you run the command mvn clean install, only the class annotated with @FastTest will be executed.
If you run the command mvn clean install -Djenkins=true (or -Pjenkins), both annotated classes will be executed.
]]>Ce qui semblait une tâche relativement simple s’est avérée être en réalité un chemin semé d’embuches…
Voici mon carnet de voyage…
Le contexte
Dans l’un de mes projets, je dispose d’une grande quantité de tests unitaires.
En réalité, parmi ceux-ci, beaucoup d’entre eux ne sont pas unitaires du tout. Ils nécessitent parfois un accès à la base Oracle, parfois un contexte Spring plutôt lourd à charger, etc. Bref, ce ne sont pas là de bons tests unitaires, lancés en isolation.
Le but est donc de pouvoir séparer les tests en diverses catégories.
Afin de simplifier les choses, je ne considèrerais que deux catégories ici : @FastTest et @SlowTest.
Solutions envisagées
JUnit a introduit dans la version 4.8 les @Category (voir le changelog et un exemple).
Le principe est d’annoter une classe (ou une méthode) avec @Category, et de définir à quelle catégorie ce(s) test(s) appartient(-nent). Pour notre besoin, nous pourrions donc écrire :
// Interfaces pour catégoriser les tests...
public interface FastTest { }
public interface SlowTest { }
@Category(SlowTest.class)
public class ASlowTest {
@Test
public void foo() { ... }
}
@Category(FastTest.class)
public class ARealUnitTest {
@Test
public void foo() { ... }
}
Bref, ça s’annonce plutôt bien. Mais si l’on regarde dans le détail, pour pouvoir lancer tous les tests d’une catégorie spécifique, il faut faire :
@RunWith(Categories.class)
@IncludeCategory(FastTest.class)
@SuiteClasses( { ARealUnitTest.class, AnotherRealUnitTest.class })
public class FastTestsSuite { }
Et c’est là notre souci : il faut créer une Suite (via l’annotation @SuiteClasses) afin de définir les classes devant être exécutées. Cela nous oblige donc à maintenir une liste exhaustive des tests à lancer pour une suite donnée. Les oublis risquent donc d’être fréquents…
Se passer des Suite JUnit
Comment pallier ce problème de Suite ? Rapidement, quelques idées me viennent :
- Ecrire des
Suitemanuellement comme on vient de le dire, mais avec le risque d’en oublier. - Ecrire des
Suitevia un plugin Maven. J’en avais écrit un dans ce but il y a environ 2 ans et je pourrais m’en resservir. Mais la question est de savoir à quel moment il doit être lancé. Etant donné que mon plugin écrit ou modifie des classes de tests, on ne peut pas l’exécuter automatiquement ni n’importe quand. De plus, il se peut que certaines classes ne doivent pas être ajoutées dans ces suites, donc on ne peut pas considérer cette solution comme viable. - Se baser sur des nommages spécifiques pour les classes de test. Par exemple tous les tests vraiment unitaires portent le nom de
***FastTest.java, les autres étant nommés***SlowTest.java. Maven, et ses profiles, se chargeant ensuite de choisir quel pattern donné à Surefire. Bien qu’il s’agisse d’une idée intéressante, je ne suis que moyennement pour, car on risque d’avoir là aussi des oublis ou des erreurs. - Utiliser TestNG, un autre framework de tests, proposant plus de fonctionnalités que JUnit. En particulier, TestNG permet de créer des groupes sur les tests, ce qui correspond à nos
@Categoryde JUnit, mais qui marchent mieux. Le plugin Maven de tests – Surefire – gère nativement le support des groupes. C’est très simple, il suffit de définir une propriété dans la configuration Maven du plugin Surefire ! Mais dans mon cas, je souhaite rester sur du JUnit, bien que cette solution soit sans doute la plus élégante… - Modifier le plugin surefire de Maven pour gérer les
@Categoryde JUnit. Ne rigolez pas, j’ai essayé de le faire
Mais modifier un plugin du coeur de Maven n’est forcément pas une bonne idée !
Sur ces cinq solutions, j’ai donc opté pour pour la sixième !
La sixième solution : Ne pas se passer des Suite !
L’idée consiste à utiliser des Suite de JUnit, mais que celles-ci soit générées dynamiquement.
Cette Suite va aller chercher dans le classpath les classes de tests annotées avec une annotation particulière.
Lors de mes recherches, je suis tombé sur le projet classpathSuite. L’un des intérêts de ce projet est de pouvoir construire une Suite en cherchant des classes présentes dans le ClassPath.
Ainsi il suffit d’écrire :
@RunWith(Categories.class)
@Categories.IncludeCategory(FastTest.class)
@Suite.SuiteClasses( { AllTests.class })
public class FastTestsSuite {
}
@RunWith(ClasspathSuite.class)
public class AllTests {
}
pour que classpathSuite cherche toutes les classes présentes dans le ClassPath appartenant à la catégorie FastTest.
Magique. Sauf que si ça marche très bien avec Eclipse, cela ne fonctionne pas lorsque les tests sont lancés par Maven.
Ou alors j’ai raté quelque chose !
Donc il faut refaire quelque chose de proche, mais qui marche avec Maven !
La solution
Première étape, je créé deux annotations simples : @FastTest et @SlowTest.
Ces annotations vont être utilisées pour annoter des classes de tests unitaires (dans cette solution, nous n’annoterons que les classes, et pas les méthodes). Grosso-modo ça remplacera les annotations @Category(FastTest.class) et @Category(SlowTest.class).
Ensuite, je crée une classe utilitaire qui va chercher dans tout le classpath les classes étant annotées par une annotation donnée (donc essentiellement @FastTest ou @SlowTest) et qui appartiennent à un package donné (ou un package fils).
Cela nous donne :
public final class ClasspathClassesFinder {
/**
* Get the list of classes of a given package name, and that are annotated by a given annotation.
*
* @param packageName The package name of the classes.
* @param testAnnotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
*/
public static Class<?>[] getSuiteClasses(String packageName, Class<? extends Annotation> testAnnotation) {
try {
return getClasses(packageName, testAnnotation);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
/**
* Get the list of classes of a given package name, and that are annotated by a given annotation.
*
* @param packageName The package name of the classes.
* @param annotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
* @throws ClassNotFoundException If something goes wrong...
* @throws IOException If something goes wrong...
*/
private static Class<?>[] getClasses(String packageName, Class<? extends Annotation> annotation) throws ClassNotFoundException, IOException {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
String path = packageName.replace('.', '/');
// Get classpath
Enumeration<URL> resources = classLoader.getResources(path);
List<File> dirs = new ArrayList<File>();
while (resources.hasMoreElements()) {
URL resource = resources.nextElement();
dirs.add(new File(resource.getFile()));
}
// For each classpath, get the classes.
ArrayList<Class<?>> classes = new ArrayList<Class<?>>();
for (File directory : dirs) {
classes.addAll(findClasses(directory, packageName, annotation));
}
return classes.toArray(new Class[classes.size()]);
}
/**
* Find classes, in a given directory (recurively), for a given package name, that are annotated by a given annotation.
*
* @param directory The directory where to look for.
* @param packageName The package name of the classes.
* @param annotation The annotation the class should be annotated with.
* @return The List of classes that matches the requirements.
* @throws ClassNotFoundException If something goes wrong...
*/
private static List<Class<?>> findClasses(File directory, String packageName, Class<? extends Annotation> annotation)
throws ClassNotFoundException {
List<Class<?>> classes = new ArrayList<Class<?>>();
if (!directory.exists()) {
return classes;
}
File[] files = directory.listFiles();
for (File file : files) {
if (file.isDirectory()) {
classes.addAll(findClasses(file, packageName + "." + file.getName(), annotation));
} else if (file.getName().endsWith(".class")) {
// We remove the .class at the end of the filename to get the class name...
Class<?> clazz = Class.forName(packageName + '.' + file.getName().substring(0, file.getName().length() - 6));
// Does the file is annotated with the given annotation?
if (clazz.getAnnotation(annotation) != null) {
classes.add(clazz);
}
}
}
return classes;
}
NB: Je me suis inspiré de ce post pour ce code, mais adapté à mes besoins.
Je n’ai pas regardé en détail, mais il est possible que le projet Reflections puisse faciliter l’écriture d’une telle classe, mais bon…
Ainsi, le code ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class) va me retourner un tableau de classes ayant comme package ancêtre my.company et annotées par @FastTest.
Je construit maintenant une Suite qui va utiliser cette précédente classe utilitaire pour me trouver les tests rapides :
public class FastTestsSuite extends org.junit.runners.Suite {
public FastTestsSuite(Class<?> clazz, RunnerBuilder builder) throws InitializationError {
this(builder, clazz, ClasspathClassesFinder.getSuiteClasses("my.company", FastTest.class));
}
public FastTestsSuite(RunnerBuilder builder, Class<?> clazz, Class<?>[] suiteClasses) throws InitializationError {
super(builder, clazz, suiteClasses);
}
}
Dernier élément, le point d’entrée de mes tests pour le plugin Maven Surefire :
@RunWith(FastTestsSuite.class)
public class RunAllFastTests {
}
Il ne me reste plus qu’à indiquer à Maven de ne prendre « que » ce test là :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Run only tests annotated with @FastTest. -->
<includes>
<include>**/RunAllFastTests.java</include>
</includes>
...
</configuration>
</plugin>
Un petit bémol : si l’on travaille avec des projets multi-modules Maven (ce qui est mon cas), il faut que chaque module dispose de sa propre classe nommée RunAllFastTests.
Concernant les SlowTest, il me suffit de définir un profile Maven qui lancera la classe RunAllSlowTests, qui fera appel à la suite SlowTestsSuite qui appelle ma classe utilitaire pour trouver toutes les classes annotées par @SlowTest. Le serveur d’Intégration Continue Hudson Jenkins activant alors ce profile lors des nightly-builds.
Conclusion
Au final, il n’y a rien de bien méchant là-dedans, le principe une fois en place est simple (il suffit d’annoter la classe JUnit avec la bonne annotation). Mais je trouve cela regrettable que JUnit, pourtant très largement utilisé, soit aussi peu flexible pour un besoin somme toute très simple.
Donc si vous trouvez que j’ai sorti l’artillerie lourde pour rien, faites m’en part dans les commentaires, je suis curieux de voir comment vous vous y seriez pris !
Bonus
Suite à une suggestion de Jean-Philippe Briend, j’ai mis à disposition le code source d’un petit projet contenant toutes les classes évoquées ici.
Le projet se builde avec Maven 2 ou 3, Java 1.6 et JUnit 4.8.1.
En plus de toutes les classes nécessaires au bon fonctionnement du mécanisme, il contient trois classes de test unitaires, pour montrer le principe en action :
OneFastTest, annotée avec@FastTest;OneSlowTest, annotée avec@SlowTest;TestWithoutAnnotation, classe non annotée. Afin de montrer que ce test n’est pas exécuté, il contient une méthode qui appelle lefailde JUnit. Ainsi, si la classe est exécutée, le test échouera.
En lançant la commande mvn clean install, seule la classe annotée avec @FastTest est exécutée.
En lançant la commande mvn clean install -Djenkins=true (ou -Pjenkins), les deux classes annotées sont exécutées.
N’hésitez pas à me faire un retour sur ce projet si vous trouvez là aussi des énormités…
Start Slide Show with PicLens Lite]]>