Génie Logiciel Avancé TP - Test unitaire avec JUnit - LRI

Prof. Burkhart Wolff
wolff@lri.fr
TP - Test unitaire avec JUnit
Semaine du 10/10/2011
Génie Logiciel Avancé
Année 2011-2012
Delphine Longuet, Lina Ye
longuet@lri.fr, lina.ye@lri.fr
L’objectif de ce TP est d’écrire et d’exécuter des tests avec JUnit pour un ensemble de
classes Java implantant un agenda. À partir de la spécification informelle donnée, vous devez
écrire un ensemble de classes JUnit de façon à pouvoir tester des implantations de l’agenda en
boîte noire. Les squelettes des classes de test ainsi que les implantations à tester sont disponibles
à l’adresse http://www.lri.fr/~longuet/Enseignements/11-12/Agenda.tar.gz.
Spécification de l’agenda On considère la classe Agenda dont chaque instance représente
l’emploi du temps d’une personne. Un emploi du temps est un ensemble d’événements dont
chacun est identifié par un nom, une date de début et une date de fin. Un événement est une
instance de la classe Evenement. Le nom d’un événement ne doit pas être vide. La durée d’un
événement s’étend entre sa date de début incluse et sa date de fin excluse. Un événement ne
peut pas avoir une durée nulle, et sa date de début doit précéder sa date de fin. La création
d’un événement qui ne respecte pas ces conditions lève l’exception ErreurEvenement.
On peut ajouter et supprimer un événement d’un agenda, chercher quel événement a lieu
à une date donnée, chercher par son nom si un événement est présent dans l’agenda, connaître
les dates de début et de fin d’un événement prévu.
Les événements d’un agenda doivent tous avoir des noms différents et ne doivent pas se
chevaucher. Un événement ne peut donc être ajouté à un agenda que si un événement de même
nom n’existe pas déjà et s’il n’est en conflit avec aucun des événements déjà présents dans
l’agenda. Ainsi, à une date donnée, un agenda contient au plus un événement. L’ajout d’un
événement renvoie un booléen permettant de savoir si l’ajout a été effectué. Il en est de même
pour la suppression d’un événement.
La recherche d’un événement à une certaine date renvoie le nom de l’événement prévu s’il
existe, le mot vide sinon. Si on cherche la date de début ou de fin d’un événement qui n’est
pas présent dans l’agenda, l’exception ErreurAgenda est levée.
Une date est en réalité une date du calendrier plus une heure de la journée (sur 24 heures).
C’est une instance d’une classe Date donnée par le jour, le mois, l’année, les heures et les
minutes. Une date doit être postérieure au 1 er janvier 1970, 0h00. La création d’une date
erronée lève l’exception ErreurDate.
Le squelette de la classe Java Agenda est le suivant.
public class Agenda {
public Agenda() { }
public boolean ajouter (Evenement e) { }
public boolean supprimer (String nom) { }
public String chercherEvenement (Date d) { }
public Date dateDebut (String nom) throws ErreurAgenda { }
public Date dateFin (String nom) throws ErreurAgenda { }
public boolean prevu(String nom) { }
}
1

Le constructeur de la classe Date a la forme :
public Date(int jour, int mois, int annee, int heure, int minute)
throws ErreurDate { }
et celui de la classe Evenement a la forme :
public Evenement(String nom, Date debut, Date fin)
throws ErreurEvenement { }
Introduction à JUnit JUnit est un outil permettant d’écrire et d’exécuter des tests unitaires
sur des programmes Java. Il est intégré à Eclipse mais est égalenemt disponible à l’adresse
http://www.junit.org/.
Les tests en JUnit sont regroupés au sein d’une classe Java qui doit hériter de la classe
TestCase. Le nom des méthodes de test doit commencer par test. Le corps d’une méthode
de test doit comporter trois parties :
– le préambule, qui permet l’initialisation des objets sur lesquels le test va être exécuté ;
– le corps de test, dans lequel la méthode à tester est appelée sur les objets créés;
– le postambule, qui permet de délivrer le verdict du test (succès ou échec) en vérifiant un
ensemble de propriétés (assertions) sur l’état des objets après le test. Le tableau 1 à la
fin de l’énoncé résume les différentes assertions possibles en JUnit.
◮ Sous Eclipse, créez un nouveau projet à partir du répertoire TestAgenda fourni. Ajoutez
JUnit3 au classpath : clic droit sur le projet > Build Path > Add Librairies > Junit3. Puis
ajoutez une des implantations de la classeAgenda fournies : clic droit sur le projet > Build Path
> Add External Archives, puis ajouter le fichier Agenda4.jar du répertoire Implantations,
par exemple.
◮ Ouvrez la classe Tests donnée en exemple. Elle contient quatre méthodes de test :
1. La méthode testDate31Janvier vérifie que la création de la date du 31 janvier 2011,
22h30 est possible (et donc que le mois de janvier a bien 31 jours). Comme la création de
cette instance de Date ne doit pas lever d’exception, le test doit échouer si une exception
est levée. On rattrape alors l’exception et on force l’échec du test avec la méthodefail().
2. La méthodetestEvenementSansNom vérifie qu’il n’est pas possible de créer un événement
dont le nom est vide. On fait échouer le test si aucune exception n’est levée, et également
si l’exception levée n’est pas celle attendue.
3. La méthode testAgendaAjouterEvenementSimple vérifie qu’il est possible d’ajouter un
événement à un agenda vide. On vérifie que l’événement a bien été ajouté à l’agenda,
c’est-à-dire qu’il est bien prévu, que ses dates de début et de fin sont correctes, et qu’on
le trouve lorsqu’on cherche quel événement a lieu à une date comprise entre son début
et sa fin. On force le test à échouer si une exception est levée au cours de l’exécution.
4. La méthode testAgendaDebutAbsent vérifie que la recherche du début d’un événement
qui n’existe pas dans l’agenda lève l’exception ErreurAgenda et ne modifie pas l’agenda.
Dans ce cas, on fait échouer le test si aucune exception n’est levée ou si l’exception
levée n’est pas correcte. On vérifie que l’agenda n’a pas été modifié en s’assurant que les
événements prévus sont les mêmes et aux mêmes dates.
◮ Pour exécuter ces tests sur une implantation en boîte noire (une archive .jar), il faut ajouter
le fichier au classpath comme vu précédemment. Exécutez ensuite Tests en tant que test JUnit
2

sur l’implantation Agenda4.jar. Le résultat des tests apparaît dans un nouvel onglet : un
test ayant levé une exception non rattrapée est répertorié dans Errors, un test ayant échoué
(AssertionFailedError) est répertorié dans Failures.
Afin de regrouper les tests selon la classe testée, on répartira les tests entre trois classes
TestDate, TestEvenement et TestAgenda. Il est possible de factoriser l’initialisation et la
remise à zéro des objets utilisés dans plusieurs tests en définissant des méthodes appelées
setUp et tearDown, qui seront exécutées respectivement avant et après chaque test.
◮ Ouvrez la classe TestAgenda qui illustre l’utilisation de ces méthodes. On remarque qu’on
rattrape également une éventuelle exception dans le corps de la méthode setUp, au cas où
l’initialisation échoue. La méthode suite sert à construire une suite de tests à partir des méthodes
setUp et tearDown et des méthodes de test. Cette suite de test correspond à l’exécution
des méthodes selon l’ordre :
setUp(); test1(); tearDown(); setUp(); test2(); tearDown(); ...
◮ Exécutez ensembleTestDate,TestEvenement etTestAgenda sur l’implantationAgenda4.jar :
clic droit sur le package > Run As > JUnit Test.
Exercice : écriture et exécution des tests
◮ Complétez les squelettes des trois classes de test fournies en suivant les exemples précédemment
donnés. En particulier, pour chacun des tests, précisez en commentaire l’objectif du
test ainsi que le résultat attendu. Pensez à tester aussi bien les cas qui doivent réussir que
les cas qui doivent lever une exception : l’objectif est de couvrir un maximum de cas. Pensez
également aux cas aux limites.
◮ Dans un fichier texte ou tableau, résumez les résultats des tests sur les 17 implantations
fournies : pour chaque implantation, dites si elle réussit ou échoue aux tests et expliquez les
fautes trouvées. Vous pouvez suivre le modèle suivant :
Implantation Résultats des tests Fautes trouvées
Agenda4 Échec Mauvais nombre de jours au mois de janvier
Méthode Rôle
assertEquals(Object a, Object b) Vérifie que les objets a et b sont égaux
assertSame(Object a, Object b) Vérifie que a et b sont des références vers le même
objet
assertNotSame(Object a, Object b) Vérifie que a et b ne sont pas des références vers
le même objet
assertNull(Object o) Vérifie que l’objet o est null
assertNotNull(Object o) Vérifie que l’objet o n’est pas null
assertTrue(boolean e) Vérifie que l’expression e est vraie
assertFalse(boolean e) Vérifie que l’expression e est fausse
fail() Provoque l’échec du test
Fig. 1 – Méthodes d’assertions en JUnit
3