Ceci est un simple article d’introduction à JUnit. Cet article sur JUnit n’a pas vocation à faire référence ; il se contente de présenter les notions de base.

Désormais plus personne ne remet en cause l’importance des tests dans le cadre du développement logiciel. Ce document s’intéresse plus particulièrement aux tests unitaires. Il existe plusieurs frameworks mais le plus populaire est incontestablement JUnit.

L’objectif de cet article est de faire connaissance avec JUnit le plus simplement possible. Or le petit monde de la programmation a déjà adopté un ensemble d’outils et de normes ; autant donc les prendre en compte dès le départ. Parmi les incontournables, nous allons prendre en compte le framework Maven, qui permet de construire les applications et de gérer simplement les dépendances.

La commande suivante est à lancer dans une fenêtre DOS (terminal) sans retour à la ligne :

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.thi.calcul -DartifactId=thi

Cette commande va créer la structure des dossiers nécessaire à la suite de cette démonstration.

Dossiers du projet (Cliquer pour agrandir)

Il faut maintenant demander à Maven de générer les fichiers pour importer le projet dans le logiciel de développement Eclipse.

cd thi mvn eclipse:eclipse

A ce stade, on en a fini ou presque avec Maven. Il ne reste plus qu’à importer le projet dans Eclipse. Dans Eclipse, choisissez le menu "File / Import", puis l’option "Existing projects into Workspace" et selectionnez le dossier ("thi") du projet dans la popup qui s’ouvre.

Import dans Eclipse (Cliquer pour agrandir)

Le projet apparait dans la zone de gauche d’Eclipse. On reconnait la structure des packages qu’on avait indiquée à Maven.

Le premier test doit être créé dans la classe "PremierTest" qui doit hériter de "junit.framework.TestCase".

package com.thi.calcul; import junit.framework.TestCase; public class PremierTest extends TestCase { }

Par convention on a l’habitude de préfixer les Méthodes de test par test. Junit va automatiquement lancer toutes les méthodes identifiées comme des tests.

JUnit propose un ensemble de méthodes pour finaliser les tests. La plus importante et la plus commune est "assertTrue(boolean)" qui valide le test si l’expression booléenne en paramètre est vraie, et l’invalide sinon.

/** * Test super simple */ public void testSimple() { assertTrue(true); }

Pour lancer un test, il suffit de faire un clic droit sur le test (ie. la méthode) qu’on veut tester.

Lancer un test (Cliquer pour agrandir)

Le résultat du test s’affiche alors dans la vue JUnit (à gauche sur la capture d’écran) en vert si le test est validé, en rouge sinon.

Résultat du test 1er test (Cliquer pour agrandir)

En général une classe de test contient de nombreux tests, l’idée sous jacente étant de bien tester chaque fonction de l’application. Eclipse peut au choix lancer les tests indépendamment ou alors tous les tests d’une classe de test d’un seul coup.

Le pendant de assertTrue(boolean) est tout naturellement assertFalse(boolean)

/** * Test égalité */ public void testEgal() { assertTrue(1 == 1); } /** * Test inversé */ public void testInverse() { assertFalse(1 == 2); }

Résultat multi-test (Cliquer pour agrandir)

Ce qui est très fort, à ce stade, c’est que Maven va automatiser non seulement la construction de l’application mais aussi le lancement des tests.

mvn clean install

[INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building thi [INFO] task-segment: [clean, install] [INFO] ------------------------------------------------------------------------ [INFO] [clean:clean] [INFO] Deleting directory D:\javadev\article\test_unitaire\thi\target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 1 source file to D:\javadev\article\test_unitaire\thi\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Compiling 1 source file to D:\javadev\article\test_unitaire\thi\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: D:\javadev\article\test_unitaire\thi\target\surefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.thi.calcul.PremierTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Results : Tests run: 3, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] Building jar: D:\javadev\article\test_unitaire\thi\target\thi-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing D:\javadev\article\test_unitaire\thi\target\thi-1.0-SNAPSHOT.jar to C:\dev\.m2\repository\com\thi\calcul\thi\1.0-SNAPSHOT\thi-1.0-SNAPSHOT.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Sun Mar 21 21:52:54 CET 2010 [INFO] Final Memory: 14M/25M [INFO] ------------------------------------------------------------------------

Pour voir le résultat de JUnit s’afficher en rouge, il suffit de créer un test qui plante. L’instruction 1 == 3 est bien évidement inexacte.

/** * Test d'un plantage */ public void testPlantage() { assertTrue(1 == 3); }

Il convient de noter que chaque test de la classe s’exécute de manière séparée. J’ai volontairement mis le test qui plante au milieu des bons tests pour montrer que ceux d’après se lancent même si un test précédent a échoué. Les tests sont lancés dans l’ordre où ils apparaissent dans la classe.

Résultat d'un plantage (Cliquer pour agrandir)

Cette fois la sortie console de la compillation Maven est un peu différente.

[INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building thi [INFO] task-segment: [install] [INFO] ------------------------------------------------------------------------ ... ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.thi.calcul.PremierTest Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.066 sec <<< FAILURE! Results : Failed tests: testPlantage(com.thi.calcul.PremierTest) Tests run: 4, Failures: 1, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please refer to D:\javadev\article\test_unitaire\thi\target\surefire-reports for the individual test results. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2 seconds [INFO] Finished at: Tue Mar 23 10:17:57 CET 2010 [INFO] Final Memory: 5M/10M [INFO] ------------------------------------------------------------------------

A noter qu’on peut demander à Maven de sauter la phase de test grâce au paramètre "maven.test.skip"

mvn install -Dmaven.test.skip=true

Il existe une forme abrégée bien pratique de cette commande (comme pour de nombreux autres paramètres de Maven) :

mvn install -Dmaven.test.skip

D:\javadev\article\test_unitaire\thi>mvn install -Dmaven.test.skip=true [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building thi [INFO] task-segment: [install] [INFO] ------------------------------------------------------------------------ [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [INFO] Building jar: D:\javadev\article\test_unitaire\thi\target\thi-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing D:\javadev\article\test_unitaire\thi\target\thi-1.0-SNAPSHOT.jar to C:\dev\.m2\repository\com\thi\calcul\thi\1.0-SNAPSHOT\thi-1.0-SNAPSHOT.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 23 10:24:53 CET 2010 [INFO] Final Memory: 8M/14M [INFO] ------------------------------------------------------------------------

La version 4 de JUnit apporte le support des annotations. C’est une petite révolution qui suit la mode actuelle.

Selon votre version de Maven, le projet sera configuré pour JUnit en version 3 ou en version 4. Pour le savoir, il suffit de regarder le fichier "pom.xml". Celui que j’ai utilisé jusqu’à ce stade spécifie "JUnit 3.8.1". Il suffit de remplacer cette valeur en "4.8" (une version récente au moment où j’écris ces lignes) par exemple et de régénérer le projet Eclipse avec la commande "mvn eclipse:eclipse" puis de lancer un "Refresh".

Voici le fichier "pom.xml" après la modification (lignes 14-15)

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.thi.calcul</groupId> <artifactId>thi</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version> <name>thi</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <!-- <version>3.8.1</version> --> <version>4.8</version> <scope>test</scope> </dependency> </dependencies> </project>

Grâce aux annotations il n’est plus nécessaire d’hériter de TestCase pour définir une classe de test. Il suffit d’annoter les méthodes avec "@Test". L'import static des méthodes est bien util à ce stade.

package com.thi.calcul; import org.junit.Test; import static org.junit.Assert.assertTrue; import static org.junit.Assert.assertEquals; public class SecondTest { @Test public void testAnnotation() { assertTrue(1 == 1); } @Test public void testEgalite() { assertEquals("toto", "toto"); } @Test public void testDivers() { assertEquals("toto", "toto"); assertTrue(1 == 1); String str = "lala"; assertEquals("lala", str); } }

Au passage on note qu’il est tout à faire possible d’inclure plusieurs assertions au sein d’un même test comme c’est fait dans la méthode "testDivers()".

Résultat des tests annotés (Cliquer pour agrandir)

On peut aussi lancer directement les tests à l’aide de Maven. C’est particulièrement utile dans le cadre du développement dirigé par les tests (test driven)

mvn test

Ce qui donne, avec notre test "testPlantage()" qui ne marche volontairement toujours pas.

D:\javadev\article\test_unitaire\thi>mvn test [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building thi [INFO] task-segment: [test] [INFO] ------------------------------------------------------------------------ [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/junit/junit/4.8/junit-4.8.pom [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: D:\javadev\article\test_unitaire\thi\target\su refire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.thi.calcul.PremierTest Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec <<< FAILURE! Running com.thi.calcul.SecondTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Results : Failed tests: testPlantage(com.thi.calcul.PremierTest) Tests run: 7, Failures: 1, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please refer to D:\javadev\article\test_unitaire\thi\target\surefire-reports for the individual test results. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2 seconds [INFO] Finished at: Tue Mar 23 12:17:28 CET 2010 [INFO] Final Memory: 4M/8M [INFO] ------------------------------------------------------------------------

Il est également possible de demander à Eclipse de lancer automatiquement tous les tests (selon des critères à configurer) comme on le fait avec CheckStyle mais je déconseille vivement cette pratique. En effet, bien qu’elle soit séduisante et pleine de sens, elle ne s’applique qu’à des petits projets. Avec l’augmentation du périmètre de l’application, les tests deviennent vite consommateurs et peuvent entraver le travail des développeurs. Il faut laisser l’initiative du lancement des tests locaux aux développeurs. Les utilisateurs d’Eclipse connaissent bien ce point.

Dans de nombreux cas, on a besoin d’initialiser les tests avant de les lancer. JUnit 3 définit la méthode setUp() pour réaliser cela. La méthode setUp() est automatiquement lancée avant chaque test.

/** * Pour initialiser */ protected void setUp() { // do things nice // Ici un print juste pour la démo System.out.println(compteur++); }

S’il y a 4 tests dans la classe alors setUp() sera lancée 4 fois.

Résultat du setUp() (Cliquer pour agrandir)

La version 4 de JUnit, quant à elle, introduit l’annotation "@Before" pour réaliser le même travail. La méthode annotée peut alors prendre n'importe quel nom. Toutefois, on essaie de conserver un nom malin.

@Before public void doBefore() { // do things nice // Ici un print juste pour la démo System.out.println("Before " + compteur++); }

Résultat du @before (Cliquer pour agrandir)

Ce qui est encore plus fort, c’est qu’il devient possible d’avoir plusieurs méthodes annotée avec "@Before".

@Before public void doBefore() { // do things nice // Ici un print juste pour la démo System.out.println("Before " + compteur++); } @Before public void myBefore2() { // do things nice // Ici un print juste pour la démo System.out.println("my before " + compteur++); }

Résultat du @before sur plusieurs méthodes (Cliquer pour agrandir)

Devinez quoi… Le "@Before" aurait dû vous mettre la puce à l’oreille car il existe bel et bien une annotation "@After" indiquant que les méthodes doivent être lancées après chaque test.

@After public void doAfter() { // do things nice // Ici un print juste pour la démo System.out.println("After " + compteur++); }

Résultat du @After (Cliquer pour agrandir)

Un peu dans la même idée, JUnit 4 propose les annotations @BeforeClass et @AfterClass qui indiquent que les méthodes annotées doivent être lancées avant et après la prise en compte de la classe de test. C’est particulièrement utile quand on doit initialiser une connexion vers la base de données par exemple. En effet ce type d’opération est lourde et couteuse (longue) donc on préfère la réaliser une seule fois pour l’ensemble de la classe au lieu de le faire à chaque test comme ce serait le cas avec @Before.

@BeforeClass public static void doBeforeClass() { // do things nice // Ici un print juste pour la démo System.out.println("Before class " + compteur++); } @AfterClass public static void doAfterClass() { // do things nice // Ici un print juste pour la démo System.out.println("After class " + compteur++); }

Résultat du @BeforeClass (Cliquer pour agrandir)

Dans certains cas, ce que l’on veut vraiment tester, c’est le lancement d’exception quand on sait que le cas d’usage est hors conditions limites. L’annotation "@Test" accepte le paramètre "expected" qui permet justement de spécifier qu’on attend que la méthode sorte en exception.

@Test(expected=NullPointerException.class) public void testThrowingNull() { String str = null; // Ici on va produire une NPE car str est null str.substring(1); }

Dans l’exemple de code, ci-dessus, le test sera validé (en vert donc) si et seulement si la méthode lance une NPE.

L’objectif d’un test unitaire n’est absolument pas de mesurer la performance d’une méthode. Toutefois JUnit offre ce type de fonctionnalité. Grâce au paramètre timeout, il est possible d’indiquer un délai limite d’exécution. Le test ne sera validé que si son exécution se déroule en moins de temps que spécifié par le paramètre timeout. Si le temps d’exécution le dépasse alors le test sera invalidé (et donc en rouge dans Eclipse)

@Test(timeout = 2000) public void testUnTrucLong() { // Do something long String slow = ""; for (int i = 0; i < 100000; i++) { slow += i; // Opération longue } }

En lançant une boucle de concaténation de String (ci-dessus) en tant que test, on est dans un cas de figure où le test peut prendre beaucoup de temps. Cette durée peut mettre le doigt sur un problème d’optimisation. Dans le cas présent, c’est un cas d’école.

Test invalidé car il dépasse 2 secondes (Cliquer pour agrandir)

On notre que Eclipse (colonne de gauche) nous donne les temps d’exécution de chaque test. Ici, on constate que le dernier test s’est effectivement déroulé en plus de 2 secondes.

JUnit est bien plus complexe et complet que ça mais l’essentiel est dit. Un autre article sera l’occasion d’aller plus loin et de découvrir les fonctionnalités puissances offertes par le framework.

Pour aller plus loin, je vous invite à lire mon article sur le framework EasyMock qui permet d'avoir une vision nouvelle des tests.

• JUnit : http://www.junit.org
• Article d'intro sur EasyMoch : cliquer ici
• Maven : http://maven.apache.org
• Eclipse : http://www.eclipse.org