Tests unitaires

Quand doit-on écrire des tests, c'est-à-dire à quelle phase du développement doit-on s'y mettre ? Sur ce point, l'une des pratiques les plus en vogue aujourd'hui, l'eXtreme Programming, nous dit de les écrire avant même de commencer à coder. Certains pratiquent aussi le pair programming (programmation en binôme) de la manière suivante : discussion du binôme autour de développement à effectuer (on ne parle pas des cinq jours à venir, mais des 30 minutes à venir) puis chacun retourne à sa machine et l'un des développeurs écrit les tests, tandis que l'autre implémente. Quoi qu'il en soit, les tests s'écrivent en même temps que le code. Légèrement avant, légèrement après ou exactement en même temps ? Peu importe votre méthode, mais vous ne devez pas écrire tous les tests d'un coup avant le développement, ni les écrire après avoir terminé l'implémentation (ce serait totalement inutile). Pour ma part, j'opte plutôt pour l'écriture des tests avant le code ; en effet, cette pratique a plusieurs avantages :

• affiner l'analyse, en particulier, si en écrivant le Javadoc avant le code, vous avez recensé les besoins, ici vous recensez les cas d'utilisations ;
• apporter l'ensemble des règles pré et postconditions traitées dans l'article sur les assertions ;
• apporter aussi l'ensemble des traitements de vérification de paramètres également traités dans un article précédent ;
• éviter d'écrire du code inutile. En effet, si vos tests (bien écris s'entend) passent tous, inutile d'ajouter du code à votre classe. Donc vous implémentez jusqu'à ce que tous les tests passent, puis vous arrêtez et passez au point suivant.

Ne vous méprenez pas sur ce titre, il ne s'agit pas de documenter le test, mais de s'en servir comme d'une documentation technique. En effet, l'utilisation de vos classes est toujours difficile à documenter. Qui plus est, une documentation à part risque fort d'être rapidement désuète. Ceci vous décourage dans l'écriture d'une documentation et vous mène souvent à la rédaction de celle-ci en fin de projet, soit beaucoup trop tard. Le test est en lui-même un exemple d'utilisation et de manipulation de vos classes, il vous permet donc de documenter celles-ci. Donc, en plus d'ajouter de la valeur logicielle, le test apporte de la valeur documentaire à vos codes, vous hésitez encore à en écrire ?

Si vous partez d'un code qui fonctionne, que vous lui ajoutez un peu de fonctionnel, où se trouve le bogue ? Dans les lignes que vous avez ajoutées bien entendu ! Donc plus vous testez régulièrement, plus le bogue est facilement détectable. Eh oui, dénicher un bogue dans deux ou trois lignes de code regroupées est beaucoup plus simple que de le détecter dans une trentaine de lignes réparties sur plusieurs classes ! Alors le problème c'est qu'aujourd'hui, vous êtes obligé d'écrire, le code métier, le code de persistance et le code de l'IHM avant de pouvoir vraiment tester quoi que ce soit. Le framework de test vous apporte donc une solution sur mesure pour résoudre ce problème : il faut quelques lignes seulement pour écrire le client graphique (même s'il ne se présente pas franchement comme l'IHM définitive). Vous vous affranchissez donc de deux problèmes en une seule fois : ne pas être obligé de coder l'interface graphique tant que le métier n'est pas implémenté, et ne pas dépendre du débogage de l'IHM elle-même pendant le codage du métier. Toujours des hésitations ?

Une fois les tests écrits, il suffit de quelques secondes pour les lancer, et obtenir un compte-rendu. Et vous obtenez en quelques secondes, ou quelques minutes si votre application est vraiment importante et que vous lancez vraiment absolument tous les tests, un compte-rendu exhaustif de ce qui marche et de ce qui ne marche pas ! Avez-vous déjà pris le temps de tester une application de manière exhaustive ? C'est pourtant ce qu'il faut faire avant de la livrer, et ce qu'il faudrait faire à chaque modification. Autant dire que même pour une application de petite taille, si vous la testez manuellement, ça vous prendra au bas mot plusieurs dizaines de minutes ! Vous ne le faites donc que rarement et ça vous est préjudiciable, vous allez encore passer des heures à déboguer un petit rien simplement parce qu'au moment où vous avez généré le bogue, vous n'avez pas tout testé ! Si vous n'êtes toujours pas convaincu par le fait qu'il faut écrire des tests, j'ai encore un paragraphe pour vous faire changer d'avis, mais vous êtes un peu dur ;-)

Combien de fois ai-je entendu "Je ne comprends pas pourquoi, hier ça marchait ! " ? Impossible de répondre… Trop souvent en tout cas. Le pire, étant certainement de l'avoir entendu sortir de sa propre bouche… Vous ne voulez plus vous entendre dire à votre responsable qu'hier ça marchait, ou vous ne voulez plus entendre vos collègues vous dire ce genre de lieu commun des développeurs. De plus, afin que la maintenance de votre code puisse être effectuée par tous, sans pour autant que de nouveaux bogues soient introduits par un tiers, il faut lever un drapeau "attention, ne marche pas comme prévu ! ". Les tests unitaires sont là pour ça. La non-régression du code, c'est donc, la certitude que l'on avance. C'est aussi la confiance qui s'installe : "je peux modifier mon code puisqu'il résiste au pire, je saurais immédiatement s'il y a bogue, où et pourquoi". Et la confiance en soi donne la force d'avancer plus vite. Alors, perdre son temps à écrire quelques tests, c'est gagner des heures de débogage (ce qui vous intéresse le moins dans votre métier j'en suis certain), ça n'est donc pas utile, mais essentiel. Dans quelques semaines, après avoir acquis suffisamment de réflexes pour l'écriture de ces tests, vous repenserez à cette période ancestrale durant laquelle vous écriviez du code sans écrire de tests, et vous vous demanderez alors comment vous faisiez.

Commençons par observer la syntaxe à respecter pour écrire un test, ensuite, nous verrons comment réunir plusieurs séries de tests pour un lancement simultané. Enfin, une fois que l'on sera capable d'écrire les tests, on essayera de débrouiller les situations pour lesquelles écrire les tests et dans quelles conditions les écrire. Une classe héritant de junit.framework.TestCase pour commencer, c'est le socle de votre série. Dans cette classe, vous pouvez définir les séries de tests tout simplement en déclarant des méthodes publiques dont le nom commence par les quatre lettres (en minuscules) test. Voilà, vous avez défini un testCase que vous pouvez passer en paramètre à un TestRunner pour lancer vos tests. C'est simple non ? Bien entendu, il reste encore à comprendre ce qu'il faut mettre dans les méthodes testXXX(). Vous n'allez pas être dépaysé si vous avez déjà lu l'article sur les assertions, car les tests se font justement à coup d'assertions. Voilà un exemple de test, je mets une méthode main()dans la classe afin de la rendre exécutable, il n'y a rien d'obligatoire à ça bien entendu.

package com.developpez.tutoriels.astuces.tests;

  /**
   * classe de test pour une pseudo classe de traitement d'une facture
   */

  public class TestFacture extends junit.framework.TestCase {
          public void main(String[] args) {
                  // pas de vérification des paramètres, ce n'est pas l'objet
                  junit.textui.TestRunner.run(TestFacture.class);
          }

          public TestFacture(String name) {
                  // ce constructeur est obligatoire, car il n'existe pas 
                  // de constructeur par défaut dans les TestCase
                  super(name);
          }

          public void testAjoutArticles() {
                  Facture maFacture = new Facture();
                  maFacture.add(new Article("article 1", 3, 150.0));
                  maFacture.add(new Article("article 2", 1, 50.0));

                  assertNotNull("La facture ne devrait pas être null", maFacture);
                  assertEquals("Le total de la facture est mal calculé",
                                  3 * 150 + 50, 0.0001,
                                  maFacture.getTotal());
                  assertEquals("Le nombre d'articles est mal calculé",
                                  4,
                                  maFacture.countArticles());
          }
          public void testValidationFacture() {
                  Facture maFacture = new Facture();
                  maFacture.add(new Article("article 1", 3, 150.0));
                  maFacture.add(new Article("article 2", 1, 50.0));
                  maFacture.valide();

                  assertTrue("la validation de la facture n'a pas eu lieu",
                                  maFacture.isValide());

                  try {
                          maFacture.add(new Article("article 3", 1, 20.20));
                         fail("facture modifiée après validation");
                  } catch (FactureException e) {
                          // interdit de modifier une facture valide donc 
                          // c'est normal d'être ici
                          
                  }
          }
  }

À remarquer tout de suite dans ce code :

• j'utilise le testRunner en mode texte, je le trouve plus pratique, car il envoie tout sur la sortie standard ou erreur et en général votre IDE permet de vous diriger directement vers le code incriminé en cas d'erreur. Il existe toutefois un testRunner AWT et un SWING qui présente les résultats de manière plus graphique. À vous de choisir ;
• je vous indique quelques méthodes assertXXX, il en existe beaucoup, leur nom est suffisamment parlant pour que je ne vous fasse pas un glossaire exhaustif ;
• l'assertion sur l'égalité de réels se fait à l'aide de trois réels, les deux réels à comparer, et une approximation ;
• les assertions d'égalités vous livrent comme message "value" expected but "value" found ;
• un message (String) peut être spécifié pour toutes les assertions, il sera livré si elles ne sont pas vérifiées ;
• enfin, le nom des méthodes testXXXX sera repris dans les messages, veillez à ce qu'il signifie quelque chose.

Comme lancer un test pour une classe est loin de tester l'application complète, il est possible de réunir les tests dans des faisceaux de tests, les TestSuite. Ensuite, leur lancement se fait de la même manière qu'avec un TestCase. Bien entendu, vous pouvez réunir plusieurs TestSuite dans un TestSuite plus important, etc. jusqu'à obtenir un test de l'application complète. Ceci est avantageux sur une application pour laquelle les tests peuvent prendre plusieurs minutes, en effet, l'intérêt des tests est de pouvoir les lancer presque toutes les cinq minutes afin de détecter très tôt les bogues.

IV-C-1. Une classe, un test▲

IV-C-2. Tests dans le même package que la classe à tester▲

IV-C-3. Scénarios▲

IV-D-1. Ne pas mettre les classes dans le même répertoire que les tests▲

IV-D-2. Ne pas écrire de tests triviaux▲

IV-D-3. Pas d'effet de bord dans les tests▲