Page 1
JUnit : développement orienté tests
CREATION : 2010/10/04
MISE A JOUR : 2010/10/11
Avec Eclipse et Netbeans, vous avez dans les mains des EDI qui se prêtent bien au développement
agile. Le développement est incrémental : on livre de nouvelles versions régulièrement avec de
nouvelles fonctionnalités. Une des difficultés est d’éviter les régressions de code. Une des méthodes
préférées des développeurs JAVA est d’utiliser des outils comme JUnit (on parle alors de
développement orienté tests si c’est bien fait).
Le principe est simple : avant d’écrire une fonctionnalité, on écrit le test qui correspond. Au début,
une application n’est pas livrable car elle échoue à tous les tests. Petit à petit, elle répond au cahier
des charges pour réussir tous les tests. Les tests sont écrits une fois pour toutes et sont répétables.
JUnit introduit un formalisme un peu spécial qui dépend de la version utilisée. Sur développez.com,
vous trouverez un tutoriel pour les versions 2 et 3, nous allons nous intéresser à la dernière version,
la 4, qui fait usage d’annotations et non plus de méthodes particulières pour lancer les tests ou les
jeux de tests.
@Test : une méthode qui réalise un test doit être annotée avec @Test. Elle ne renvoie rien ni
n’accepte de paramètre. Si la méthode doit renvoyer une exception, elle est précisée avec le champ
expected.
Tout test annoté par @Ignore (avec éventuellement une chaîne de caractères pour info) doit être
ignoré par le générateur de test.
Les méthodes annotées par @Before et @After sont exécutées respectivement avant et après
chaque test. @BeforeClass et @AfterClass ne sont exécutées qu’une seule fois par classe de test, les
méthodes doivent être statiques. On appelle toutes ces méthodes des fixtures.
Il est aussi possible d’utiliser des assertions : celles du java standard (mot réservé assert) et celles de
JUnit (classe Assert avec ses méthodes).
Partie 1 : Mise en place de la classe à tester
Nous allons utiliser JUnit pour le développement minimaliste de la
classe Livre dont la représentation UML est donnée ci-contre.
• Créer la classe Livre avec ses attributs et générer
automatiquement le code des autres méthodes
Source > Generate Constructor using Fields
Source > Generate Getters and Setters
Source > Generate Hashcode et equals en se limitant à l’attribut prix
Page 2
• Corriger l’indentation du code
• Renommer equals() en equals2()
• Refaire une méthode equals() qui renvoie toujours faux.
La classe Object définit deux méthodes equals() et hashCode() qui doivent être cohérentes pour
déterminer si deux instances sont équivalentes ou pas.
Partie 2 : Mise en place des jeux de test
• Créer une nouvelle classe (par exemple : LivreTest) qui testera le code que l’on vient d’écrire
avec les raccourcis :
o (M) File > New > New JUnit Test.
o (D) Sélectionner JUnit 4
o Eclipse pourra vous demander d’ajouter la bibliothèque JUnit au projet courant.
• Déclarer trois instances de Livre : instancier les trois objets dans une méthode init() précédée
de l’annotation @BeforeClass : deux avec le même titre mais des prix différents et l’autre
avec un autre titre
• Créer une méthode testEquals() précédée de l’annotation @Test qui teste si les titres des
livres sont bien égaux ou pas avec assertTrue() et assertFalse()
• Enlever les erreurs de compilation avec les bons imports (statiques ou non)
• Exécuter la classe avec JUnit. Relever les différentes erreurs
• Ecrire une nouvelle méthode testEquals2() qui fait la même chose avec equals2().
• Retester
• Placer @Ignore devant testEquals() et retester
A vous d’intégrer désormais JUnit pour vos prochains TPs ou projets. Seule ou avec d’autres classes,
vous pourrez faire des choses très sympathiques. La plateforme Java propose parfois des classes
étonnantes comme java.awt.Robot qui permet de simuler le comportement d’un utilisateur (saisie
d’un caractère, clic de souris, déplacement de souris).