JUnit est le framework de test unitaires
en Java. Il est désormais bien connu des développeurs Java et on le trouve
intégré à la majorité des IDE, Eclipse et NetBeans en tête.
Se servir de JUnit est une chose. Ecrire des tests efficaces en est une autre. Ce post n'a pas la prétention de livrer toutes les bonnes pratiques qui entourent JUnit, mais donne quelques trucs qui peuvent servir à un moment ou à un autre.
1- Définissez une classe de base pour vos tests
Un test JUnit doit hériter de junit.framework.TestCase.
Cependant, pour un projet donné, on a souvent intérêt à créer une classe de
base pour tous les tests JUnit. Par exemple, pour le projet "Titato" :
/**
* All tests inherit this class.
*/
public abstract clas TitatoTestCase extends
junit.framework.TestCase {
}
Puis chaque test du projet hérite de cette classe :
/**
* Test of ASpecificClass class.
*/
public class ASpecificClassTest extends TitatoTestCase {
(...)
}
L'intérêt ? Avoir un endroit où définir des méthodes utilitaires qui
pourront être utilisées par tous les tests du projet. Par exemple, JUnit ne
propose pas d'assertion pour comparer le contenu de tableaux de byte. Si on a
souvent besoin d'une telle assertion, TitatoTestCase est l'endroit
approprié pour définir une telle méthode : elle sera accessible depuis
tous les tests.
2- Pour les larges comparaisons, préférez assertEquals(String,
String)
Toutes les assertions se valent... à priori. Pourtant, il y en a une qu'Eclipse traite différemment : la comparaison de chaine. Si on compare deux chaines différentes, Eclipse effectue un diff. Très pratique lorsque les chaines sont longues.
La comparaison :
public void testStrings() {
assertEquals(
"This is a string\nAnd this is another one",
"This is a string\nAnd this is another ONE!");
}
produit :
Pour tirer parti de cette fonctionnalité, il suffit de rappeler
assertEquals(String, String), plutôt qu'une de ses variantes.
Prenons une comparaison de liste :
public testGetPeopleList() {
ArrayList<String> expected = new ArrayList<String>();
expected.add("John");
expected.add("Bob");
expected.add("Paul");
expected.add("Michael");
assertEquals(expected, getPeopleList());
}
En exécutant le test tel quel, Eclipse livre un message peu lisible :
junit.framework.AssertionFailedError: expected:<John, Bob, Paul, Michael> but was:<John, Bob, Paul, Greg, Michael>
Il y a une différence, mais quelle est-elle au juste ?
En ramenant les listes à des chaines, on se simplifie la vie. Définissons
assertEquals(ArrayList<String>, ArrayList<String>),
probablement dans la classe mère des tests JUnit du projet, afin que celle-ci
soit utilisable partout :
public void assertEquals(
ArrayList<String> expected,
ArrayList<String> observed) {
// Let's call assertEquals(String, String)
assertEquals(toString(expected), toString(observed));
}
private String toString(ArrayList<String> list) {
String result = "";
for (String s: list) {
result += s + "\n";
}
return result;
}
Cette fois-ci, l'erreur est évidente :
Dans toString(ArrayList<String> list), il est important
de noter qu'on insère des sauts de ligne entre chaque item de la liste. C'est
important puisque cela va avoir un impact sur la présentation du diff. Sans
cela, Eclipse affiche un diff portant sur une unique ligne. Nettement moins
lisible.
3- Ne prenez pas de risque pour le test d'exception
Les tests négatifs nécessitent régulièrement de vérifier qu'on obtient une exception en cas d'appel erroné :
public void testTouchyMethod {
try {
// touchyMethod shall throw a SomeException
touchyMethod();
fail("An exception was expected");
}
catch(SomeException e) {
// Correct case
}
}
Le point faible de ce type de construction vient de l'appel à la méthode
fail de JUnit, invoquée si touchyMethod retourne au
lieu de lancer une exception. Cet appel est vite oublié. Si tel est le cas, le
test ne sert à rien, tout en donnant l'impression inverse.
Afin d'éviter ce risque, on peut implémenter un helper :
public abstract class ExceptionTester extends TestCase {
public abstract void runTestedAction() throws Throwable;
public ExceptionTester(Class expectedClass) {
try {
runTestedAction();
}
catch (Throwable t) {
assertEquals(expectedClass, t.getClass());
return;
}
fail("Expected " + expectedClass + " but got no error");
}
}
Puis, lorsqu'on a besoin de vérifier un lancement d'exception :
public void testFailingMethod() {
new ExceptionTester(Exception.class) {
@Override
public void runTestedAction() throws Throwable {
touchyMethod();
}
};
}
Cette seconde version n'est guère plus compacte, mais là n'est pas l'intérêt. Les avantages :
- Par le jeu de la complétion des IDE modernes, elle est beaucoup plus rapide
à saisir. Notamment, Eclipse va déclarer
runTestedActionde lui-même. - Cette forme est plus sûre : pas d'appel à
failà oublier.
4- Utilisez des fichiers sans dépendre de leur chemin absolu
Un test doit pouvoir d'exécuter dans tout environnement. Lorsqu'on a besoin d'utiliser un fichier à partir d'un test, il est tentant d'utiliser un chemin absolu mais nous savons tous où cela mène...
La solution
généralement recommandée est d'utiliser getResource et
getResourceAsStream :
InputStream is = this.getClass().getResourceAsStream("data.txt");
C'est un début. Utiliser ces méthodes directement présente néanmoins une
difficulté. Comme elles prennent comme référence le répertoire de la classe, le
test JUnit dans notre cas, on doit souvent se fendre d'un conséquent
"../../../.." avant d'atteindre le répertoire ciblé.
Une bonne technique est de régler ces problème une fois pour toute, dans la classe mère des tests JUnit du projet :
public InputStream getResourceAsStream(String path)
throws IOException {
// Get the path of the JUnit test base class
URL url = SampleTestCase.class.getResource(
"TitatoTestCase.class");
// Get the directory of the class
// (ie. the TitatoTestCase.class file)
// This method assume that TitatoTestCase is not located
// in a JAR file
File file = new File(url.getPath());
// Here, the "/../" depends on the project layout
return new FileInputStream(file.getParent() + "/../" + path);
}
Cette méthode doit être adaptée pour chaque projet :
"TitatoTestCase.class"dépend du nom de la classe de base des tests JUnit.- Dans la dernière ligne,
"/../"est destiné à se placer au niveau du projet. Ce composant dépend de l'endroit où est compilée la classe ainsi que son package.
Enfin, chaque test peut ouvrir un fichier :
getResourceAsStream("test/test_data/data.txt");
5- Test de séquences complexes : utilisez des traces sous la forme de String
Certain tests consistent à vérifier que telle ou telle méthode a bien été appelée. C'est régulièrement le cas lorsqu'on implémente le design pattern Template method.
Prenons l'exemple d'une classe FileHelper. Cette classe possède
une méthode process qui prend en paramètre un nom de fichier ainsi
qu'un FileProcessor. FileProcessor est une interface
dotée de 3 méthodes :
fileOpened(String fileName): appelée lorsque le fichier à traiter est ouvert ;lineRead(String line): appelée pour chaque ligne du fichier traité ;fileClosed(): appelé lorsque le fichier traité est fermé.
Lorsqu'on appelle FileHelper.process("myFile.txt", aProcessor),
on s'attend à la équence suivante :
aProcessor.fileOpenedest appelé avec"myFile.txt";aProcessor.lineReadest appelé pour chaque ligne du fichier ;aProcessor.fileClosedest appelé.
Comment tester FileHelper.process ? Une solution pratique
est de tracer l'exécution au sein d'une instance de FileProcessor
et de comparer cette trace avec le résultat attendu.
On commence par créer un fichier d'exemple, nommé
data_for_filehelper_process.txt :
This is a sample file to test FileHelper.process Bye!
On implémente FileProcessor. Cette implémentation ne fait rien
d'autre que sauver la trace des méthodes qui sont appelées :
public class TestProcessor implements FileProcessor {
String trace = "";
public void fileOpened(String fileName) {
trace += "fileOpened(" + fileName + ")\n";
}
public void lineRead(String line) {
trace += "lineRead(" + line + ")\n";
}
public void fileClosed() {
trace += "fileClosed()\n";
}
public String getTrace() {
return trace;
}
}
Il ne reste plus qu'à implémenter le test :
public void testProcess() {
TestProcessor processor = new TestProcessor();
// For an idea of how getResourcePath should work,
// see previous section above
FileHelper.process(getResourcePath(
"test/test_data/data_for_filehelper_process.txt"),
processor);
// Check the trace
assertEquals(
"fileOpened(data_for_filehelper_process.txt)\n" +
"lineRead(This is a sample file)\n" +
"lineRead(to test FileHelper.process)\n" +
"lineRead(Bye!)\n" +
"fileClosed()\n",
processor.getTrace());
}
Si FileHelper.process est buggué et omet de lire la dernière
ligne du fichier, on obtiendra sous Eclipse :
Bon test avec JUnit !
