Les tests

Introduction

Quand un client commande un développement, un cahier des charges est rédigé décrivant des fonctionnalités de haut niveau sous forme de cas concrets d’utilisation. C’est ce document qui servira plus tard à valider les développements effectués. Ces cas d’utilisation vont mettre en action de nombreux objets développés par l’équipe. Ces objets vont communiquer entre eux avec des méthodes et des chronologies mûrement réfléchies pendant l’analyse. Chaque échange s’effectuera la plupart du temps avec des paramètres aller et retour. Les rangs admissibles de ces paramètres seront connus et ces objets fonctionneront généralement parfaitement bien quand ils recevront ce qu’ils attendront au moment où ils les attendront. Mais que se passera-t-il quand le cadencement s’emballera ou que les paramètres passés seront hors limites ?

La solidité d’une application se révèle dans les cas extrêmes par des traitements adaptés des défauts et une bonne protection des données. Pour gagner ce degré de fiabilité, il faut avant tout que chaque maillon de la chaîne reste stable, quelles que soient ses conditions d’exploitation. Pour cela, il faut les éprouver en les poussant dans leurs limites....

Environnement d’exécution des tests unitaires

Il est toujours possible d’écrire des « petites applications » autonomes permettant d’éprouver les objets de la future « grande application ». Par exemple, un code chargé dans une console pourra instancier la classe à tester, puis dérouler une série d’appels affichant des messages d’erreur ou écrivant les résultats dans un fichier. C’est tout à fait possible, mais… pas très pratique.

IntelliJ IDEA avec l’environnement de tests Java JUnit 5 simplifient la rédaction, l’exécution et l’analyse des tests unitaires. Pas besoin de petites applications autonomes ; IntelliJ IDEA propose directement la préparation d’un ensemble de tests que le développeur pourra jouer en totalité, en groupe (playlist) ou individuellement grâce à l’explorateur de tests. Les résultats des tests sont synthétisés dans une vue type arbre utilisant les couleurs jaune et vert, et permettant d’aller rapidement, en cas d’échec, sur la ligne de code défaillant. Il est possible d’exécuter les tests en mode Debug et donc de « tracer » les méthodes appelées dans les objets à fiabiliser.

Le projet avec tests unitaires

Les tests sont des méthodes de classes que l’on ajoute, la plupart du temps, au projet contenant les classes à tester, en s’aidant des assistants d’IntelliJ IDEA.

package demo.tests; 
 
public class Vecteur { 
 
    private int x; 
    private int y; 
 
    public int getX() { 
        return x; 
    } 
 
    public void setX(int x) { 
        this.x = x; 
    } 
 
    public int getY() { 
        return y; 
    } 
 
    public void setY(int y) { 
        this.y = y; 
    } 
 
    public void Ajouter(Vecteur v) 
    { 
        x += v.x; 
        y += v.x;    //Erreur de codage 
        // aurait dû être y += v.y;  
    } ...

La classe de tests

Le code de départ de notre classe de test est le suivant :

package demo.tests; 
import org.junit.jupiter.api.Test; 
 
import static org.junit.jupiter.api.Assertions.*; 
 class VecteurTest { 
 
    @Test 
    void ajouter() { 
    } 
} 

On y trouve le package contenant la classe VecteurTest qui elle-même contient la méthode ajouter.

Chaque méthode de tests doit être précédée par l’attribut @Test qui la distinguera d’éventuelles autres méthodes de la même classe.

Contenu d’une méthode de test

Le test va être exécuté directement dans l’environnement de développement et ne nécessitera donc ni méthode main d’une classe et ni projet particulier. Le code de la méthode de test doit instancier la classe cible, appeler une de ses méthodes puis valider le comportement attendu. Normalement, dans le cadre de tests unitaires, il ne doit y avoir qu’une action sur l’objet par test.

Par exemple, pour une méthode Additionner, le test vérifie que si 2 et 3 sont passés en paramètres, alors le résultat retourné sera bien 5.

Les vérifications utilisent la classe Assertions du package org.junit. jupiter.api qui propose une collection de méthodes offrant des services beaucoup plus complets que ceux associés au mot-clé assert utilisé jusqu’alors dans cet ouvrage.

Parmi ce jeu de méthodes se trouvent la méthode assertTrue et ses surcharges. 

(extrait de https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html) 

Dans cette forme, cette méthode permet de vérifier qu’une condition est vraie et, si elle ne l’est pas, de retourner un message de votre choix dans l’explorateur de tests.

Traitements de préparation et de nettoyage

L’exécution des tests peut être précédée par des traitements d’initialisation et suivie par des traitements de « nettoyage ». Ces traitements facultatifs sont écrits dans des méthodes décorées d’attributs spéciaux qui définissent à quel moment elles seront exécutées par le script.

Extrait de code montrant la syntaxe de toutes les méthodes d’initialisation

package demo.tests; 
 
import org.junit.jupiter.api.*; 
 
public class AutresTests { 
 
    public AutresTests(){ 
        System.out.println("Constructeur de la classe de tests"); 
    } 
 
    @BeforeAll 
    public static void avantTout(){ 
        System.out.println("Avant de lancer les tests (...)"); 
    } 
 
    @AfterAll 
    public static void apresTout(){ ...

Les tests avec paramètres externes

Imaginons que nous ayons à tester le comportement d’une méthode dans des centaines de cas d’utilisation. Écrire et maintenir la collection d’informations dans le code sera difficile et tout changement nécessitera la recompilation des tests : pas très pratique  ! Externaliser ses listes dans des fichiers puis effectuer leurs chargements et leurs itérations dans le test lui-même est envisageable, mais est-ce le rôle du test ? S’appuyer sur l’environnement de développement pour alimenter nos tests en données est, de loin, la solution la plus confortable et c’est ce que nous propose JUnit 5 ! On parle alors de « data-driven unit tests »...

La démonstration qui suit utilise une collection au format CSV (Comma-Separated Values). C’est en l’occurrence un fichier de format texte très simple où chaque ligne représente une collection de paramètres séparés par des virgules. On peut facilement obtenir un fichier .csv à partir d’un fichier Excel grâce à sa fonction d’exportation.

Exercice

String initiales = ClasseChaine.RetourneInitiales("Andreas Dulac"); 
// initiales doit contenir "A.D." 

package lab.tests; 
 
import static org.junit.jupiter.api.Assertions.*; 
 
public class ClasseChaineTest { 
 
    @org.junit.jupiter.api.Test 
    void testCasNormal() { 
        String initiales...