IN201 : JUnit

IN201 : JUnit
SUPAERO 2A
Christophe Garion <[email protected]>
Ce document est un guide succinct sur JUnit, un framework de test unitaire pour Java.
Le problème principal qui se pose en « informatique » est de pouvoir vérifier, voire prouver, que les
développements que l’on fait sont corrects :
– au sens de ce qu’attend le client (fonctionnalités) ;
– que tout est intégrable (i.e. que les classes développées peuvent interagir entre elles) ;
– au niveau de la classe enfin (est-ce que les méthodes font bien ce que l’on veut ?).
Nous ne nous intéresserons ici qu’au troisième cas, i.e. nous nous attacherons à vérifier que les méthodes
des classes ont un comportement correct. Pour cela nous nous appuierons sur une classe Point minimale,
sans documentation que nous allons tester.
public class Point {
private double x;
private double y;
public Point(double x_, double y_) {
this.x = x_;
this.y = y_;
}
public double getX() {
return this.x;
}
public double getY() {
return this.y;
}
public double getModule()
{
return (Math.sqrt(this.x * this.x + this.y * this.y));
}
public double getArgument()
{
if (this.getModule()==0) {
return 0;
}
double ancienArg = Math.acos(this.x/this.getModule());
if (this.y<0) {
return(-1 * ancienArg);
}
return(ancienArg);
1
}
public void translater(double dx, double dy) {
this.x += dx;
this.y += dy + 1;
}
public void setModule(double module)
{
double ancienModule = getModule();
if (ancienModule==0) {
this.x = module;
}
else {
this.x = (this.x * module)/ancienModule;
this.y = (this.y * module)/ancienModule;
}
}
public void setArgument(double arg)
{
double ancienModule = this.getModule();
x = ancienModule * Math.cos(arg);
y = ancienModule * Math.sin(arg);
}
public double distance(Point p) {
return Math.sqrt(Math.pow(this.x - p.x, 2) +
Math.pow(this.y - p.y, 2));
}
}
Pour pouvoir tester les méthodes de la classe Point, nous allons utiliser JUnit, un framework de test
automatisé1 [1].
1
1.1
Installation et utilisation de JUnit
Installation
JUnit est un ensemble de classes disponibles sous forme d’une archive JAR s’appelant junit.jar. On
peut charger depuis [1] une archive ZIP contenant l’archive JAR nécessaire. On peut la placer n’importe
où a priori. Il est à noter que si l’on utilise Eclipse, l’archive JAR est fournie avec Eclipse.
1.2
Utilisation en ligne de commande
Si l’on veut utiliser JUnit depuis la ligne de commande, il faut inclure l’archive junit.jar dans le CLASSPATH. Au Centre Informatique, l’archive se trouve dans /opt/junit3.8.1. Pour pouvoir positionner le
CLASSPATH, deux solutions existent :
1 Attention, ici automatisé ne signifie pas que JUnit va écrire les tests automatiquement. Il va simplement simplifier
l’écriture, le lancement et la gestion des tests.
2
1. positionner
la
variable
d’environnement
CLASSPATH
via
la
commande
Cette commande peut être
exécutée dans un terminal (et alors toutes les commandes de compilation et d’exécution effectuées
dans ce terminal tiendront compte du nouveau CLASSPATH) ou peut être placée dans le fichier
d’initialisation de votre shell (~/.bashrc, ~/.zshrc etc).
export CLASSPATH=$CLASSPATH:/opt/junit3.8.1/junit.jar.
2. donner explicitement le chemin vers l’archive à chaque compilation avec javac ou exécution avec
java en utilisant l’option -classpath. Par exemple :
javac -d ../classes -classpath ../classes:/opt/junit3.8.1/junit.jar *.java
java -classpath .:/opt/junit3.8.1/junit.jar fr.supaero.figures.TestPoint
1.3
Utilisation avec Eclipse
L’utilisation d’Eclipse facilite grandement la manipulation de JUnit. Pour pouvoir créer une classe de
test (nous reviendrons dessus dans ce qui suit), il suffit de cliquer droit sur la classe que l’on veut tester,
de choisir « JUnit Test Class » et les archives nécessaires seront importées. On peut alors choisir quelles
seront les méthodes à tester.
Lorsque l’on utilise des classes de tests provenant d’une source extérieure (lors des TP par exemple),
Eclipse ne va ajouter automatiquement les archives nécessaires. Il faut alors cliquer droit sur votre projet,
puis choisir « Properties », « Java Build Path », « Librairies » et choisir « Add External Jars ». Ajouter
ensuite l’archive junit.jar que l’on peut trouver :
– au Centre Informatique dans le répertoire /opt/junit3.8.1 ;
– généralement, dans le répertoire où vous avez installé Eclipse sous plugins/org.junit_3.8.1. Par
exemple /usr/share/eclipse-3.0.2/plugins/org.junit_3.8.1.
2
Écrire une classe de test JUnit
On peut se demander comment tester. Y-a-t’il en particulier une « procédure » classique de test ? On
a l’habitude d’utiliser les 3A (Acteur, Action et Assertion) :
– l’acteur est un objet sur le lequel le test va porter ;
– l’action est une action qui consiste à appeler la méthode à tester sur l’acteur ;
– l’assertion est une propriété (vraie ou fausse) qui vérifie que l’action a bien eu l’effet escompté.
Par exemple, pour la méthode translater de la classe Point :
– on initialise un point de coordonnées (1, 2) ;
– on le translate avec un vecteur (2, 3) ;
– on vérifie que les nouvelles coordonnées du point sont (3, 5).
2.1
Architecture d’une classe de test JUnit
Une classe de test minimale est composée des éléments suivants :
import junit.framework.TestCase;
public class TestPoint extends TestCase {
public TestPoint (String name){
super(name);
}
3
protected void setUp() {
}
}// TestPoint
La méthode setUp permet d’initialiser les acteurs dont on aura besoin dans le test. Elle est appelée
avant chaque test, donc les acteurs sont réinitialisés avant chaque test de méthode par exemple.
Les acteurs doivent être des attributs de la classe de test, car ils seront manipulés par toutes les
méthodes de test de la classe. Par exemple :
private Point p;
private Point q;
...
protected void setUp() {
this.p = new Point(1,2);
this.q = new Point(2,3);
}
2.2
Écriture des méthodes de test
Lorsque l’on veut écrire une méthode de test pour la méthode translater par exemple, on va écrire
une méthode testTranslater. Toutes les méthodes dont le nom commence par test sont considérées
comme des méthodes de test. C’est dans ces méthodes que nous allons modifier l’état des acteurs et
vérifier des assertions. Par exemple :
public void testTranslater() {
p.translater(3,6);
Assert.assertEquals(4.0, p.getX(), 0.0);
Assert.assertEquals(8.0, p.getY(), 0.0);
}
Les actions correspondent à des appels de méthodes sur les acteurs. Les assertions sont écrites en
utilisant la classe Assert qui possède de nombreuses méthodes statiques permettant de vérifier des
conditions :
– assertEquals(String expected, String actual) qui permet de vérifier si deux chaı̂nes de caractères sont identiques ;
– assertEquals(double exp, double actual, double delta) qui permet de vérifier que deux
réels sont égaux à un delta près ;
– assertEquals(int expected, int actual) qui permet de vérifier que deux entiers sont égaux ;
– assertFalse(boolean condition) qui permet de vérifier qu’une condition est fausse ;
– assertTrue(boolean condition) qui permet de vérifier qu’une condition est vraie ;
– assertNotNull(Object object) qui permet de vérifier qu’une poignée ne référe pas null ;
– assertNull(Object object) qui permet de vérifier qu’une poignée référe null ;
– assertSame(Object expected, Object actual) qui permet de vérifier que deux poignées référent
le même objet (pour l’égalité avec equals, utiliser assertEquals) ;
– assertNotSame(Object expected, Object actual) qui permet de vérifier que deux poignées ne
référent pas le même objet ;
– ...
4
Si une des conditions exprimées via ces méthodes dans une méthode de test n’est pas vraie, alors le
test échoue. Les messages d’erreur sont suffisamment explicites, en particulier le framework vous indique
quelle était la valeur attendue et quelle était la valeur réelle.
Vous trouverez la javadoc de ces méthodes sur le site de documentation de JUnit (à SUPAERO, en
local sur /opt/junit3.8.1/javadoc/index.html).
2.3
Lancement du test
Pour « exécuter » la classe de test, on utilise la commande suivante :
java junit.textui.TestRunner TestPoint
On obtient alors la sortie suivante :
.......F.
Time: 0,016
There was 1 failure:
1) testTranslater(TestPointMin)junit.framework.AssertionFailedError:
expected:<8.0> but was:<9.0>
at TestPointMin.testTranslater(TestPointMin.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at TestPointMin.main(TestPointMin.java:57)
FAILURES!!!
Tests run: 8,
Failures: 1,
Errors: 0
Le framework nous indique que la méthode testTranslater a échoué et que l’assertion qui a échoué
attendait un résultat de 8 et a obtenu 9 (la méthode translater de Point est fausse, elle ajoute
systèmatiquement 1 à l’ordonnée du point).
On peut également avoir une sortie graphique avec :
java junit.swingui.TestRunner TestPoint
On obtient alors une interface graphique représentée sur la figure 1.
On peut lancer le test depuis la classe de test en écrivant la méthode main suivante dans TestPoint :
}
public static void main(String[] args) {
junit.textui.TestRunner.run(TestPoint.class);
}
En
remplaçant
junit.textui.TestRunner.run(TestPoint.class);
par
junit.swingui.TestRunner.run(TestPoint.class); dans le main, on utilise l’affichage graphique.
Il est à noter que sous Eclipse, il suffit d’exécuter la classe de test.
Voici la classe de test complète pour Point :
import
import
import
import
junit.framework.Test;
junit.framework.TestCase;
junit.framework.TestSuite;
junit.framework.Assert;
5
Fig. 1 – Interface graphique de JUnit
public class TestPoint extends TestCase {
private Point p;
private Point q;
public TestPoint (String name){
super(name);
}
protected void setUp() {
this.p = new Point(1,2);
this.q = new Point(2,3);
}
public void testGetX() {
Assert.assertEquals(1.0, p.getX(), 0.0);
}
public void testGetY() {
Assert.assertEquals(2.0, p.getY(), 0.0);
}
public void testGetArgument() {
Assert.assertEquals(Math.acos(p.getX()/p.getModule()), p.getArgument(), 0.0);
}
6
public void testGetModule() {
Assert.assertEquals(Math.sqrt(p.getX() * p.getX() + p.getY() * p.getY()), p.getModule(), 0.0)
}
public void testSetArgument() {
p.setArgument(3);
Assert.assertEquals(3.0, p.getArgument(), 1E-10);
}
public void testSetModule() {
p.setModule(4);
Assert.assertEquals(4.0, p.getModule(), 1E-10);
}
public void testTranslater() {
p.translater(3,6);
Assert.assertEquals(4.0, p.getX(), 0.0);
Assert.assertEquals(8.0, p.getY(), 0.0);
}
public void testDistance() {
Assert.assertEquals(Math.sqrt(2), p.distance(q), 0.0);
}
public static void main(String[] args) {
junit.textui.TestRunner.run(TestPoint.class);
}
}// TestPoint
2.4
Construire des suites de test
Normalement, lorsque l’on modifie une partie d’un logiciel, une classe par exemple, on doit vérifier
que les changements n’impactent pas les classes utilisant la classe modifiée. Ce sont des tests de nonrégression. En utilisant JUnit, on ne va pas lancer toutes les classes de test, ce serait trop fastidieux. On
peut par contre créer une classe de test regroupant toutes les classes de tests dans une suite de tests. Par
exemple, pour les classes de test sur les figures géométriques, on peut écrire la classe suivante :
package fr.supaero.figures;
import
import
import
import
junit.framework.Test;
junit.framework.TestCase;
junit.framework.TestSuite;
junit.framework.Assert;
/**
*
*
*
*
*
<code>TestGeneral</code> est une classe permettant de lancer tous
les tests.
@author <a href="mailto:[email protected]">Christophe Garion</a>
@version 1.0
7
*/
public class TestGeneral {
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
public static Test suite() {
TestSuite suite = new TestSuite("Tous les tests sur les figures");
suite.addTest(new TestSuite(TestPolygone.class));
suite.addTest(new TestSuite(TestPoint.class));
suite.addTest(new TestSuite(TestPointNomme.class));
suite.addTest(new TestSuite(TestSegment.class));
suite.addTest(new TestSuite(TestEnsemblePoint.class));
return suite;
}
}
On
peut
remplacer
junit.textui.TestRunner.run(suite())
junit.swingui.TestRunner.run(TestGeneral.class) si l’on veut utiliser l’interface graphique.
Références
[1] JUnit. http://www.junit.org.
8
par