📘 Développer des tests automatisés

1. Rôle et usage des frameworks de test

1.1. Difficultés du test automatisé

Comme évoqué précédemment, le test automatisé nécessite d’implémenter une suite de scénarios de test sous la forme d’un ensemble de plusieurs scripts de test (aussi appelés programmes de test). Lorsqu’il est lui-même exécuté, un script de test est capable de jouer un scénario de test sans intervention humaine.

Le terme script ici ne fait pas référence à la notion (approximative) de langage de script utilisée communément dans le monde logiciel pour désigner des langages comme Bash ou Perl. Dans ce chapitre, un script de test désigne plus généralement un morceau de code exécutable qui permet de jouer un scénario de test, ce qui peut donc désigner aussi bien à un script Bash, une fonction Python, ou une méthode Java.

Exemple 1. Scripts de test en Java implémentant une suite de tests unitaires pour PALINDROME

On se propose de désormais tester PALINDROME de manière unitaire, en s’intéressant uniquement à son composant interne devant implémenter l’interface Java Palindrome suivante :

package app;

interface Palindrome {
    /**
     * Verifies that a word is a palindrome.
     * Ignores the character case.
     * 
     * @return true if word is a palindrome, false otherwise.
     * @throws NullPointerException if word is null
     * @throws IllegalArgumentException if word is empty 
     *                                  or contains a digit, 
     *                                  or contains a special character.
     **/
    boolean isPalindrome(String word) throws IllegalArgumentException, NullPointerException;
}

Pour l’implémentation, on a choisi d’implémenter cette interface Java à l’aide d’une classe appelée BasicPalindrome. On développe donc un ensemble de scripts de test pour cette classe, étant donné la spécification de son interface Palindrome :

package app;

public class ManualBasicPalindromeTest {

    public static void main(String[] args) throws IllegalArgumentException {

        // Variables pour le résultat total
        int passedTest = 0;
        int totalTests = 0;

        // Préparation d'un objet BasicPalindrome
        Palindrome palindrome = new BasicPalindrome();

        // Execution du 1er scénario de test
        System.out.print("Test [\"" + "anna" + "\"," + "true" + "] ");
        boolean result = palindrome.isPalindrome("anna");

        // Oracle du 1er scénario de test
        if (result == true) {
            System.out.println("succeeded");
            passedTest++;
        } else {
            System.out.println("failed");
        }
        totalTests++;

        // Execution du 2e scénario de test
        System.out.print("Test [\"" + "john" + "\"," + "false" + "] ");
        boolean result2 = palindrome.isPalindrome("john");

        // Oracle du 2e scénario de test
        if (result2 == false) {
            System.out.println("succeeded");
            passedTest++;
        } else {
            System.out.println("failed");
        }
        totalTests++;

        // Execution du 3e scénario de test
        System.out.print("Test [\"" + "ann4" + "\"," + "IllegalArgumentException" + "] ");
        boolean exceptionThrown = false;
        try {
            palindrome.isPalindrome("ann4");
        } catch (IllegalArgumentException e) {
            exceptionThrown = true;
        }

        // Oracle du 3e scénario de test
        if (exceptionThrown == true) {
            System.out.println("succeeded");
            passedTest++;
        } else {
            System.out.println("failed");
        }
        totalTests++;

        // Synthèse des résultats
        System.out.println("\nResult: " + passedTest + "/" + totalTests);
    }

}

Exécution des scripts de test (une fois compilés) :

$ java -jar palindrome-test.jar

Test ["anna",true] succeeded
Test ["john",false] succeeded
Test ["ann4",IllegalArgumentException] succeeded

Result: 3/3

Cependant, comme on peut le voir sur l’exemple ci-dessus, ce travail d’implémentation fait face à un certain nombre d’obstacles, notamment :

Gestion des oracles : chaque oracle doit être programmé manuellement, généralement à l’aide de conditionnelles (if) et d’opérateurs de comparaison.
Gestion des erreurs : une suite de tests devrait se poursuivre même si l’un de ses scripts de test rencontre une erreur, ce qui n’est pas le cas ici.
Gestion des résultats : tous les résultats obtenus par l’exécution des scripts de test (réussite, échec, ou erreur − ainsi que les causes des échecs et erreurs) doivent être stockés et fournis au développeur sous une forme lisible et exploitable.

1.2. Notion de framework de test

Afin de faciliter la tâche d’implémentation des scripts de test, il est possible et fortement conseillé d’utiliser des outils dédiés à cette tâche, à savoir des frameworks de test.

Un framework de test est généralement composé de deux parties :

Une bibliothèque logicielle qui facilite l’écriture des scripts de test, avec notamment :
- la possibilité de déclarer explicitement quelle partie du code correspond à un script de test (et donc à un scénario de test),
- des fonctions utilitaires appelées des assertions aidant à la définition d’oracles,
- des fonctionnalités pour éviter trop de redondances dans le code de test, notamment en ce qui concerne la préparation des données de test.
Un exécuteur qui est capable d’exécuter un ensemble de scripts de test écrits avec le framework, et avec les propriétés suivantes :
- chaque script de test est exécuté séparément des autres,
- si un script de test ne passe pas (erreur ou échec), les autres scripts de test sont tout de même exécutés,
- les résultats sont collectés et rassemblés dans un rapport lisible et exploitable.

Si on résume en un schéma d’ensemble, avec en orange tout ce qui est dérivé de la spécification, et en rouge ce qu’on souhaite tester :

Figure 1. Rôle d’un framework de test

2. Zoom sur JUnit

2.1. Présentation

Le framework de test JUnit, aujourd’hui dans sa version 6, est l’un des principaux outils de test logiciel utilisés dans le monde. Il permet d’écrire des scripts de test à l’aide du langage Java, et de nombreux environnements s’intègrent avec son exécuteur (Maven, Eclipse, IntelliJ, etc.).

Figure 2. Logo de JUnit

Bien qu’il puisse être utilisé pour toutes sortes de scénarios de test, JUnit est particulièrement utile pour la programmation de scénarios de tests unitaires dédiés à des logiciels implémentés en Java. En effet, comme les scripts de test sont eux-même écrits en Java, il est alors possible de directement appeler des méthodes Java importées depuis le logiciel testé.

Malgré son nom, JUnit n’est pas restreint au test unitaire, et peut être utilisé pour tout type de tests − y compris système !

Cette partie du cours ne fait qu’effleurer une partie des possibilités offertes par JUnit. Pour plus d’informations, la documentation officielle de JUnit est très fournie et bien écrite.

2.2. Utiliser Jupiter, la bibliothèque JUnit

Avant toute chose, afin d’être compilable, le projet contenant le scripts de test doit posséder une dépendance vers la bibliothèque JUnit, aussi appelée Jupiter.

Nous allons voir un aperçu de comment gérer cette dépendance dans un projet Java via un projet Maven.

2.2.1. Dépendance via un projet Maven

Un projet Maven impose par défaut une structure précise qui sépare le code source du logiciel de celui des scripts de test. Cette structure distingue le répertoire src/main/java où se trouve le code source du logiciel, et src/test/java où se trouve le code source des script de test.

Exemple 2. Exemple de structure de projet pour le logiciel Palindrome

├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── app
    │           └── Palindrome.java
    │           └── BasicPalindrome.java
    └── test
        └── java
            └── app
                └── BasicPalindromeTest.java

Une fois ce point pris en compte, pour ce qui est de la dépendance à JUnit, il faut aller dans le pom.xml et ajouter une dependency vers junit-jupiter :

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>6.1.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

On pourra ensuite compiler le projet avec à la fois le logiciel et ses tests à l’aide de la commande :

$ mvn test-compile

2.2.2. Déclarer une suite de tests et un scénario de test

Comme un très grand nombre de frameworks de test, JUnit repose sur l’idée que chaque suite de tests prendra la forme d’une classe, et que chaque scénario de test sera implémenté sous la forme d’une méthode de cette classe. Cette méthode sera donc ici notre script de test.

En outre, pour que les scripts de test soient reconnus par l’exécuteur :

Chaque classe de test doit avoir un nom qui se termine par le suffixe Test.
Chaque script de test doit être une méthode Java possédant l’annotation @Test, ainsi que optionnellement l’annotation @DisplayName pour décrire l’objectif du test.

Exemple 3. Début de réécriture de la même suite de tests avec JUnit 5

package app;

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class EmptyBasicPalindromeTest {

    @Test
    @DisplayName("Can detect that a word is a palindrome")
    public void testCanDetectPalindrome() throws IllegalArgumentException {
        // TODO
    }

    @Test
    @DisplayName("Can detect that a word is not a palindrome")
    public void testCanDetectNotPalindrome() throws IllegalArgumentException {
        // TODO
    }

    @Test
    @DisplayName("Reject a word with a special character")
    public void testRejectSpecialCharacter() throws IllegalArgumentException {
        // TODO
    }

}

On peut remarquer que ce programme Java n’a pas de main ! L’explication se trouve dans l’exécuteur JUnit qui possède son propre main qui va se charger de trouver et d’exécuter par lui-même toutes les méthodes décorées avec @Test.

2.2.3. Programmer un script de test

On peut ensuite remplir un script de test avec toutes les parties du scénario de test que l’on souhaite implémenter, à savoir : la préparation (si nécessaire), l’exécution, et l’oracle.

Pour la définition de la préparation et de l’exécution, on utilise du pur Java.
Pour la définition de l’oracle, un mécanisme est nécessaire pour vérifier que le comportement observé est bien le bon, et pour stocker le résultat obtenu (erreur, réussite, ou échec). Avec JUnit, cela passe par l’appel à des méthodes statiques d'assertion fournies par la classe org.junit.jupiter.api.Assertions. Chacune de ces méthodes prend en entrée une condition − ou simplement les données nécessaires à la vérification d’une condition − ainsi qu’un message à afficher en cas d’échec (optionnel). Lors de l’appel d’une méthode d’assertion, une condition est vérifiée, et :
- soit la condition est vraie, et le test se poursuit,
- soit la condition est fausse, et le scénario de test est interrompu et marqué comme étant un échec.
Ainsi, un scénario de test sera marqué comme une réussite s’il arrive à son terme sans avoir rencontré d'erreur − à savoir une exception Java non attrapée − et sans avoir rencontré un échec − à savoir une condition non vérifiée par un appel d’assertion effectué par l’oracle.

Attention à ne pas confondre les méthodes assertXXX fournies par JUnit, avec le mot-clé assert fourni au sein même du langage Java ! Il est très recommandé de toujours utliser les méthodes assertXXX fournies par JUnit car :

Le mot-clé assert n’est par défaut jamais exécuté en Java, et n’est activé que si l’option -ea est donnée à la JVM exécutante.
Les méthodes assertXXX produisent de bien meilleurs messages en cas d’échec. Par exemple, assertEquals(1, 2) donnera java.lang.AssertionError: expected:<1> but was:<2>, tandis que assert(1 == 2); donnera juste java.lang.AssertionError.
L’usage du mot-clé assert au sein de scénarios de tests JUnit n’est pas supporté par certains outils, comme par exemple PIT (voir chapitre sur la approche par mutation).

L’essentiel des méthodes d’assertion de JUnit

Méthode Description

Méthode	Description
`assertTrue(boolean condition)`	Vérifie qu’une condition est vraie.
`assertFalse(boolean condition)`	Vérifie qu’une condition est fausse.
`assertEquals`	Vérifie que deux éléments sont égaux (note: la méthode `equals` sera appelée si elle existe).
`assertNotEquals`	Vérifie que deux éléments ne sont pas égaux (note: la méthode `equals` sera appelée si elle existe).
`assertArrayEquals`	Vérifie que deux tableaux contiennent des valeurs égales.
`assertIterableEquals(Iterable<?> expected, Iterable<?> actual)`	Vérifie que deux itérables (ex. des collections) contiennent des valeurs égales.
`assertSame(Object expected, Object actual)`	Vérifie que deux objets sont bien le même objet (avec l’opérateur `==`).
`assertNotSame(Object unexpected, Object actual)`	Vérifie que deux objets ne sont pas le même objet (avec l’opérateur `!=`).
`assertLinesMatch(List<String> expectedLines, List<String> actualLines)`	Vérifie qu’un texte correspond à un texte modèle pouvant contenir des expressions régulières. Peut servir à analyser qu’une sortie console ou qu’un fichier produit respecte bien un format attendu.
`assertNull(Object actual)`	Vérifie que l’objet est `null`.
`assertNotNull(Object actual)`	Vérifie que l’objet n’est pas `null`.
`assertTimeout(Duration timeout, Executable executable)`	Vérifie que l’exécution d’un `Executable` (ex. une lambda expression) se termine avant un temps donné.
`assertTimeoutPreemptively(Duration timeout, Executable executable)`	Vérifie que l’exécution d’un `Executable` (ex. une lambda expression) se termine avant un temps donné, et interrompt l’exécution si le temps est dépassé.
`assertThrows(Class<T> expectedType, Executable executable)`	Vérifie que l’exécution d’un `Executable` (ex. une lambda expression) produit bien une exception d’un certain type.
`assertDoesNotThrow(Executable executable)`	Vérifie que l’exécution d’un `Executable` (ex. une lambda expression) ne produit pas d’exceptions.
`fail()`	Met le test en échec sans vérifier de condition.

assertTrue(boolean condition)

Vérifie qu’une condition est vraie.

assertFalse(boolean condition)

Vérifie qu’une condition est fausse.

assertEquals

Vérifie que deux éléments sont égaux (note: la méthode equals sera appelée si elle existe).

assertNotEquals

Vérifie que deux éléments ne sont pas égaux (note: la méthode equals sera appelée si elle existe).

assertArrayEquals

Vérifie que deux tableaux contiennent des valeurs égales.

assertIterableEquals(Iterable<?> expected, Iterable<?> actual)

Vérifie que deux itérables (ex. des collections) contiennent des valeurs égales.

assertSame(Object expected, Object actual)

Vérifie que deux objets sont bien le même objet (avec l’opérateur ==).

assertNotSame(Object unexpected, Object actual)

Vérifie que deux objets ne sont pas le même objet (avec l’opérateur !=).

assertLinesMatch(List<String> expectedLines, List<String> actualLines)

Vérifie qu’un texte correspond à un texte modèle pouvant contenir des expressions régulières. Peut servir à analyser qu’une sortie console ou qu’un fichier produit respecte bien un format attendu.

assertNull(Object actual)

Vérifie que l’objet est null.

assertNotNull(Object actual)

Vérifie que l’objet n’est pas null.

assertTimeout(Duration timeout, Executable executable)

Vérifie que l’exécution d’un Executable (ex. une lambda expression) se termine avant un temps donné.

assertTimeoutPreemptively(Duration timeout, Executable executable)

Vérifie que l’exécution d’un Executable (ex. une lambda expression) se termine avant un temps donné, et interrompt l’exécution si le temps est dépassé.

assertThrows(Class<T> expectedType, Executable executable)

Vérifie que l’exécution d’un Executable (ex. une lambda expression) produit bien une exception d’un certain type.

assertDoesNotThrow(Executable executable)

Vérifie que l’exécution d’un Executable (ex. une lambda expression) ne produit pas d’exceptions.

fail()

Met le test en échec sans vérifier de condition.

Liste complète : https://docs.junit.org/6.1.0/api/org.junit.jupiter.api/org/junit/jupiter/api/Assertions.html

Toutes ces méthodes existent en plusieurs variantes à l’aide de surcharge d’opérateur (ex. assertEquals possède une variante par type de données). Notamment, chaque méthode possède une variante permettant d’ajout d’un message à afficher en cas d’échec.

Vérification des exceptions Java avec l’assertion assertThrows

Il est courant que la spécification indique qu’une opération Java doit, dans des conditions bien précises, produire une exception d’un certain type. Il devient alors nécessaire de tester cette partie de la spécification, autrement dit de tester qu’une exception est bien produite dans les conditions spécifiées.

Mais comment faire pour vérifier la bonne présence d’une exception, étant donné qu’une exception est censée interrompre l’exécution ?

Supposons qu’on teste une méthode statique imaginaire shouldThrowExceptionWithNegativeNumbers(int number), dont la spécification indique qu’elle doit renvoyer une exception Java de type IllegalArgumentException lorsqu’on l’appelle sur un nombre négatif. On souhaite donc tester que cette exception est bien produite dans cette situation.

Une solution naive serait de procéder ainsi :

@Test
public void testExceptionNegativeNumber() {

    try {
        shouldThrowExceptionWithNegativeNumbers(-1); (1)
    } catch (IllegalArgumentException e) {
        return; (2)
    }

    fail(); (3)
}

1	Exécution qui devrait produire une `IllegalArgumentException`.
2	Si on atteint ce point, c’est qu’une `IllegalArgumentException` a été produite, donc tout est correct, donc on sort du test (qui est par défaut une réussite).
3	Si on atteint ce point, c’est que le `return` n’a pas été exécuté, donc pas d’objet `IllegalArgumentException` de produit, donc on échoue le test.

Heureusement, il est possible d’éviter cette écriture alambiquée en reposant sur l’assertion assertThrows fournie par JUnit 5. Cette assertion a de particulier qu’elle prend en premier paramètre le type de l’exception attendue (par exemple ici IllegalArgumentException), et en second paramètre une expression lambda contenant le morceau de code devant produire l’exception du type spécifiée.

Le premier paramètre de assertThrows s’écrit avec le suffixe .class, qui est nécessaire en Java pour transformer un type (comme une interface ou classe) en valeur pouvant être utilisée comme paramètre.
Le second paramètre de assertThrows s’écrit avec la notation () → {} propre aux expressions lambda, où les parenthèses contiennent les paramètres de l’expression lambda — dans notre cas, une liste vide — et où les accolades contiennent le code à exécuter — dans notre cas, le code devant produire l’exception

Ainsi, si on réécrit notre exemple avec assertThrows, on peut écrire notre script de test en une seule ligne bien plus lisible :

@Test
public void testExceptionNegativeNumber() {
    assertThrows(IllegalArgumentException.class, () -> {
        shouldThrowExceptionWithNegativeNumbers(-1);
    });
}

Exemple 4. Implémentation des scripts de test pour Palindrome (suite de l’exemple précédent)

package app;

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class BasicPalindromeTest {

    @Test
    @DisplayName("Can detect that a word is a palindrome")
    public void testCanDetectPalindrome() throws IllegalArgumentException {
        // Given
        Palindrome palindrome = new BasicPalindrome();

        // When
        boolean result = palindrome.isPalindrome("anna");

        // Then
        assertTrue(result);
    }

    @Test
    @DisplayName("Can detect that a word is not a palindrome")
    public void testCanDetectNotPalindrome() throws IllegalArgumentException {
        // Given
        Palindrome palindrome = new BasicPalindrome();

        // When
        boolean result = palindrome.isPalindrome("john");

        // Then
        assertFalse(result);
    }

    @Test
    @DisplayName("Reject a word with a special character")
    public void testRejectSpecialCharacter() throws IllegalArgumentException {
        // Given
        Palindrome palindrome = new BasicPalindrome();

        // When + Then
        assertThrows(IllegalArgumentException.class, () -> {
            palindrome.isPalindrome("ann4");
        });
    }

}

2.3. Utiliser l’exécuteur

Une fois les scripts de test codés et compilés il faut les confier à l’exécuteur JUnit. Cela peut se faire de différentes manières, notamment :

Via l’intégration JUnit au sein d’un IDE comme IntelliJ, qui fournit généralement un type de lancement particulier associé à une vue graphique qui synthétise les résultats d’exécution des tests :
Via un appel manuel dans un terminal de la méthode main de la classe org.junit.platform.console.ConsoleLauncher. Pour cela, on peut reposer sur une distribution standalone de JUnit qui prend la forme d’un unique jar que l’on peut appeler de la manière suivante :
```
$ java -jar junit-platform-console-standalone-1.6.0.jar \
    --class-path=<répertoire avec le code> \
    --scan-class-path
```
Ou bien via le plugin Maven SureFire qui se charge de lancer l’exécuteur JUnit à notre place. Ce plugin est toujours chargé par Maven par défaut, mais dans une version aujourd’hui désuète qui détecte mal les tests à exécuter. Il est donc indispensable de tout de même déclarer dans le pom.xml l’usage du plugin maven-surefire-plugin sur une version récente. On ajoute donc au pom.xml ceci :
```
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.5.6</version>
        </plugin>
    </plugins>
</build>
```
Ensuite il suffit de lancer :
```
mvn test
```

Si vous utilisez une version de Maven supérieure ou égale à 3.9.0, alors vous n’avez pas besoin de déclarer une dépendance à maven-surefire-plugin, car ce dernier sera automatiquement chargé à la bonne version.

Une fois lancé, le déroulement d’un appel à l’exécuteur est le suivant (version simplifiée):

Toutes les classes dont le nom se termine par Test et contenant des scripts de test (@Test) sont détectées dans le classpath Java et sont mémorisées.
Pour chaque classe de test détectée (dans un ordre indéterminé) :
1. Pour chaque script de test (méthode annotée avec @Test) de la classe de test, et dont le nom commence par test (dans un ordre indéterminé) :
  1. Une instance de la classe de test est créée,
  2. La méthode annotée avec @Test est exécutée,
  3. L’instance de la classe de test est détruite.
Une synthèse des résultats est produite et est affichée ou écrite dans un fichier.

Comme une instance de la classe de test est créée pour chaque exécution d’un test, on peut décider d’y stocker des attributs sans risque d’effet de bord entre les différents tests.

Exemple 5. La même suite de tests exécutée de différentes manières

Toujours avec la même suite de tests, voyons les trois manières différentes d’exécuter les scripts de test :

Après compilation du logiciel (dans un répertoire target/classes) et des tests (dans un répertoire target/test-classes), on peut appeler l’exécuteur JUnit manuellement :

$ java -jar junit-platform-console-standalone-6.1.0.jar \
    execute \
    --class-path=target/classes:target/test-classes \
    --scan-class-path

💚 Thanks for using JUnit! Support its development at https://junit.org/sponsoring

╷
├─ JUnit Platform Suite ✔
├─ JUnit Jupiter ✔
│  ├─ BasicPalindromeTest ✔
│  │  ├─ Reject a word with a special character ✔
│  │  ├─ Can detect that a word is a palindrome ✔
│  │  └─ Can detect that a word is not a palindrome ✔
└─ JUnit Vintage ✔

Test run finished after 106 ms

On voit qu’il nous indique que testCanDetectPalindrome et testCanDetectNotPalindrome ont été exécutés et sont des réussites, en affichant chaque script via sa description disponible dans le champ @DisplayName.

Plus couramment, on peut également lancer les tests à l’aide du plugin Maven JUnit, qui se charge de lancer l’exécuteur à notre place :

$ mvn test
[INFO] Scanning for projects...
[INFO]
[INFO] ----------------------< fr.univnantes:palindrome >----------------------
[INFO] Building palindrome 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------

... plein de détails sur la compilation ...

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running app.BasicPalindromeTest
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 s - in app.PalindromeTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.783 s
[INFO] Finished at: 2020-02-21T10:23:12+01:00
[INFO] ------------------------------------------------------------------------

Cette fois on ne voit pas les noms des scripts de test, mais on voit que deux tests ont été exécutés avec succès.

Enfin, troisième option, on peut appeler l’exécuteur JUnit depuis un IDE comme IntelliJ, et on obtient le résultat suivant sous forme graphique :

2.3.1. Entrelacer du code au sein des tests pour éviter les redondances

Il arrive fréquemment que les même étapes de préparations aient lieu d’un scénario de test à un autre (ex. préparer des données de test), ou bien qu’une préparation doive être faite une seule et unique fois avant tous les tests (ex. lancer une base de données).

Pour éviter que de telles redondances apparaissent dans le code des scripts de test, JUnit fournit différentes annotations supplémentaires permettant d'entrelacer du code entre les exécutions des scripts de test :

Une méthode statique annotée avec @BeforeAll sera exécutée une seule fois avant tous les scripts de test de sa classe.
Une méthode statique annotée avec @AfterAll sera exécutée une seule fois après tous les scripts de test de sa classe.
Une méthode annotée avec @BeforeEach sera exécutée une seule fois avant chaque script de test de sa classe.
Une méthode annotée avec @AfterEach sera exécutée une seule fois après chaque script de test de sa classe.

En prenant en compte ces nouvelles annotations, on obtient alors le déroulement complet lors d’un appel à l’exécuteur :

Toutes les classes dont le nom se termine par Test et contenant des scripts de test (@Test) sont détectées dans le classpath Java et sont mémorisées.
Pour chaque classe de test détectée (dans un ordre indéterminé) :
1. Toutes les méthodes statiques annotées avec @BeforeAll sont exécutées (dans un ordre indéterminé).
2. Pour chaque méthode annotée avec @Test de la classe de test, et dont le nom commence par test (dans un ordre indéterminé) :
  1. Une instance de la classe de test est créée.
  2. Toutes les méthodes annotées avec @BeforeEach sont exécutées (dans un ordre indéterminé).
  3. La méthode annotée avec @Test est exécutée
  4. Toutes les méthodes annotées avec @AfterEach sont exécutées (dans un ordre indéterminé).
  5. L’instance de la classe de test est détruite.
3. Toutes les méthodes statiques annotées avec @AfterAll sont exécutées (dans un ordre indéterminé).
Une synthèse des résultats est produite et est affichée ou écrite dans un fichier.

Si vous utilisez également l’annotation @Nested pour structurer votre code de test (voir Section 3.1.1), le comportement diffère de la manière suivante : lors de l’exécution d’une méthode située dans une classe @Nested, d’abord le @BeforeEach de la classe parente est exécuté, puis le @BeforeEach de la classe @Nested est exécuté. Cela peut permettre d’avoir un @BeforeEach spécifique à un sous-ensemble de méthodes.

Exemple 6. Amélioration des scripts de test de l’exemple précédent avec @BeforeEach

package app;

import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class ImprovedBasicPalindromeTest {

    Palindrome palindrome;

    @BeforeEach
    public void setUp() {
        // Given
        palindrome = new BasicPalindrome();
    }

    @Test
    @DisplayName("Can detect that a word is a palindrome")
    public void testCanDetectPalindrome() throws IllegalArgumentException {
        // When
        boolean result = palindrome.isPalindrome("anna");

        // Then
        assertTrue(result);
    }

    @Test
    @DisplayName("Can detect that a word is not a palindrome")
    public void testCanDetectNotPalindrome() throws IllegalArgumentException {
        // When
        boolean result = palindrome.isPalindrome("john");

        // Then
        assertFalse(result);
    }

    @Test
    @DisplayName("Reject a word with a special character")
    public void testRejectSpecialCharacter() throws IllegalArgumentException {
        // When + Then
        assertThrows(IllegalArgumentException.class, () -> {
            palindrome.isPalindrome("ann4");
        });
    }
}

3. Conseils et bonnes pratiques de développement de tests

3.1. Séparation du code de test

Le code de test d’un logiciel doit être complètement séparé du code du logiciel , soit dans le même projet mais dans un répertoire à part (comme avec Maven par défaut) ou bien dans un dépôt de code dissocié du dépôt du projet initial. Cette séparation est nécessaire pour faciliter l’ajout de nouveaux tests, pour découpler totalement le code du logiciel de ses tests et pour faciliter le futur déploiement ou conditionnement du projet.

Par défaut, Maven exige déjà que vos tests soit dans le répertoire src/test/java, qui est séparé du répertoire src/main/java contenant les sources du logiciel testé.

En outre, lorsqu’on teste un même projet à différents niveaux (unitaire, intégration, système, sécurité, etc.), il est recommandé d’organiser les différents types de test dans des dossiers distincts et explicitement nommés pour améliorer la lisibilité des scénarios de test du logiciel. Ce compartimentage permet également de faciliter l’exécution d’un seul type de test dans le cas de suites de tests très complètes et parfois longues à exécuter en totalité.

Pour rappel, on ne s’intéressera dans ce cours qu’au cas du test unitaire, ce qui signifie que cette séparation en niveaux ne sera pas demandée en travaux pratiques.

3.1.1. Organisation du code de test unitaire

Lorsqu’on fait du test unitaire , on prépare généralement une suite de tests (elle-même sous la forme d’une classe) par classe à tester. Puis, au sein d’une suite de tests, il est recommandé qu’un script de test ne couvre qu'un seul scénario de test pour faciliter la localisation d’une erreur. Cela signifie que si on a identifié 7 scénarios de tests pour une méthode, on produira 7 scripts de test unitaires distincts.

De plus, on rappelle que l’on souhaite tester l’intégralité des méthodes utilisables depuis l’extérieur d’une classe, donc toutes les méthodes avec une visibilité public ou package pour s’assurer de la stabilité de la spécification de notre logiciel.

Enfin, pour améliorer la lisibilité d’un fichier de test, une bonne pratique consiste à organiser ensemble toutes les méthodes qui testent la même unité de travail (à avoir une méthode, dans le contexte du test unitaire). JUnit propose le décorateur @Nested pour créer des classes de test internes qui peuvent être utilisées pour ranger ensemble les tests autour d’une même unité de travail.

Exemple 7. Exemple de proposition d’organisation d’un fichier de test unitaire

public class BaseAppUnitTest {

    @Nested
    @DisplayName("Test method 'incredibleMethod'")
    class TestIncredibleMethod {

        @Test
        @DisplayName("When condition1 expect result1")
        public void TestIncredibleMethodWhenCondition1() {
            ...
        }

        @Test
        @DisplayName("When condition2 expect Exception")
        public void TestIncredibleMethodWhenCondition2() {
            ...
        }
    }

    @Nested
    @DisplayName("Test method 'amazingMethod'")
    class TestAmazingMethod {

        @Test
        @DisplayName("When condition1 and condition2 expect result1")
        public void TestAmazingMethodWhenCondition1AndCondition2() {
            ...
        }

    }
}

Comme sur les scripts de test, il est également possible d’ajouter le décorateur @DisplayName sur une classe interne annotée avec @Nested pour spécifier plus en détail son contenu.

L’usage de @Nested va influencer le fonctionnement et l’usage de @BeforeEach et de @BeforeAll, voir Section 2.3.1.

3.2. Structurer un script de test en Given-When-Then

Comme mentionné dans le point précédent, une bonne pratique est de s’assurer que chaque script de test couvre exactement un seul scénario de test. Cela signifie qu’il est possible de s’aligner directement sur la définition d’un scénario de test pour structurer le contenu d’un script de test.

Pour rappel un scénario de test doit comporter :

Des données d’entrée,
Une procédure d’exécution,
Un oracle.

Une manière bien connue de reproduire cette structure au sein d’un script de test est le motif Given-When-Then :

La partie given (qui peut se traduire en "étant donné") décrit l’environnement avant l’exécution du comportement vérifié par le test − autrement dit les données d’entrée du scénario.
La partie when (qui peut se traduire en "lorsque") décrit le déclenchement du comportement vérifié − autrement dit la procédure d’exécution du scénario.
La partie then (qui peut se traduire en "alors") décrit ce qui doit être observé suite à l’exécution du comportement vérifié − autrement dit l'oracle du scénario.

Pour rendre cette structure explicite, on peut faire apparaître ces trois mots dans des commentaires comme dans différents exemples JUnit déjà montrés dans ce chapitre.

3.3. Bien implémenter un oracle de test

Nous avons vu que l’oracle d’un scénario peut être implémentée à l’aide de méthodes d’assertions fournies par un framework de test. Voici deux conseils supplémentaires concernant l’implémentation d’un oracle de test :

Si l’oracle d’un scénario de test nécessite de vérifier des choses différentes au sein des données de sortie, il est tout à fait possible d’utiliser plusieurs assertions au sein d’un même script de test − c’est même préférable plutôt que d’écrire une seule grande expression avec assertTrue. Par exemple, plutôt que d’écrire :
assertTrue(list.contains(x) && list.size() == 3);
il est préférable d’écrire :
assertTrue(list.contains(x)); assertEquals(3, list.size());
Afin de permettre au framework de test de produire des rapports de test lisibles et des messages exploitables, il est important de prendre soin d'utiliser la bonne méthode d’assertion pour une tâche donnée, et d’éviter notamment de reposer trop sur assertTrue ou assertFalse pour des expressions complexes. Par exemple on évite d’écrire :
assertTrue(x.equals(y))
et on préfère écrire :
assertEquals(x, y)
Et de même on évite d’écrire :
assertEquals(list1.size(), list2.size()); for(int i = 0, i< list1.size(); i++) { assertEquals(list1.get(i), list2.get(i)); }
et on préfère écrire :
assertIterableEquals(list1, list2)

3.4. Bien nommer les variables contenant les données d’entrée

Un script de test étant du code (qui devra être lu et maintenu), il est tout à fait pertinent de viser une bonne qualité de code également pour le code de test. L’une des bonnes pratiques récurrentes dans la qualité de code est de bien nommer les différents élément d’un programme, notamment les variables et attributs.

Il et courant de préparer des données d’entrée soit dans dans de variables dans la partie given du script, soit dans de attribut de la classe de test initialisés au sein d’une méthode @BeforeEach. Dans les deux cas, un bon nommage sera essentiel pour bien clarifier l’intention de la donnée de test.

Exemple 8. Nommage de données d’entrée de PALINDROME

Pour tester la méthode isPalindrome, on peut préparer des variables nommées ainsi :

wordWithDigit : un mot avec un chiffre,
wordWithSpecialCharacter : un mot avec un caractère spécial,
emptyWord : un mot vide,
nullWord : un mot null,
validPalindromeWord : un mot valide qui est un palindrome,
validNotPalindromeWord : un mot valide qui n’est pas un palindrome.

3.5. Ne jamais utiliser `try/catch` dans un test

En Java, le compilateur est très exigeant en ce qui concerne la déclaration et la gestion de exceptions dans le code. Un appel d’une méthode qui est susceptible d’envoyer une exception doit :

soit être à l’intérieur d’un bloc try/catch,
soit se trouver au sein d’une méthode qui annonce la possibilité qu’elle envoie une exception, à l’aide du le mot-clé throws.

Lorsqu’on implémente un script de test, il arrivera le moment où on appelle la méthode testée (partie when du test). Or, il est très courant que la méthode testée soit capable d’envoyer des exceptions, et possède donc un throws dans sa signature. Dans ce cas, le compilateur Java refusera de compiler le script de test, même si aucune exception n’est censée se produire dans le scénario de test souhaité.

Supposons qu’on souhaite tester la méthode methodWithException suivante :

public class MyClass {
    public boolean methodWithException throws ExampleException {
        …
    }
}

On implémente ensuite le script de test suivant, dont le code ne compile pas car la règle Java rappelée plus haut n’est pas respectée :

@Test
public void testException_doesNotCompile() {
    // Given
    MyClass myObject = new MyClass();
    // When
    boolean result = myObject.methodWithException(); // Cette ligne ne compile pas !
    // Then
    assertTrue(result);
}

Pour satisfaire le compilateur, une première solution est de mettre notre appel de méthode dans un bloc try/catch de la sorte, en prenant soin de faire échouer le test avec fail() si une exception apparaît :

@Test
public void testException_bad() {
    // Given
    MyClass myObject = new MyClass();
    // When
    try {
        boolean result = myObject.methodWithException();
        // Then
        assertTrue(result);
    } catch (ExampleException e) {
        fail();
    }
}

Bien que désormais cela compile et fonctionne, le code source du script s’alourdit et perd en lisibilité. C’est donc une solution à éviter autant que possible.

Une alternative beaucoup plus simple est d'ajouter un throws à la signature du script de test afin de déclarer que le script de test est susceptible d’envoyer une exception :

@Test
public void testException_good() throws ExampleException {
    // Given
    MyClass myObject = new MyClass();
    // When
    boolean result = myObject.methodWithException();
    // Then
    assertTrue(result);
}

Cette solution est largement préférable car permet au code d’être plus léger et lisible. C’est également cohérent avec ce qui est souhaité, car si il s’avère que methodWithException produise bel et bien une exception durant l’exécution du script (alors que le scénario stipule qu’il ne devrait pas y avoir d’exception), JUnit va recevoir cette exception et automatiquement considérer que le résultat du test est une erreur, et donc que le test ne passe pas. On aura donc avec succès observé une défaillance.

3.6. Isolation et indépendance des tests

Tous les scripts de test (unitaire et autres) doivent pouvoir être exécutées dans n’importe quel ordre, de manière indépendante et fournir un résultat constant (toujours le même, quel que soit l’environnement d’exécution).

Pour s’assurer de l’isolation et de l’indépendance des scripts de test d’une suite, il est possible de modifier les paramètres de l’exécuteur pour rendre l’ordre de lancement des tests aléatoire. Avec le framework JUnit, on peut modifier l’ordre d’exécution des tests en utilisant le décorateur @TestMethodOrder. Pour rendre l’exécution aléatoire sur une classe de test :

@TestMethodOrder(MethodOrderer.Random.class)
public class BaseAppUnitTest {
    ...
}

3.7. Le test : un outil de documentation du code

Au même titre que la documentation interne des méthodes d’une classe ou d’une interface, les fichiers de test d’un projet peuvent être considérés comme une source de documentation technique fiable pour les développeur⋅euse⋅s. Il est parfois intéressant d’aller consulter les cas de tests d’une bibliothèque ou d’un projet pour s’imprégner de l’implémentation de ses méthodes ou pour avoir plus d’informations sur l’utilisation de ses fonctionnalités.

En conséquence, la lisibilité, la clarté et la simplicité des tests sont des critères importants à prendre en compte lors de l’implémentation d’une suite de tests sur un projet.

3.8. Pour aller plus loin : intégration continue et dépendances externes

Pour terminer ce chapitre, quelques points supplémentaires avancés et optionnels pour aller plus loin :

Si un processus d’intégration continue est en place dans un projet logiciel, alors en principe tous les tests unitaires seront ré-exécutés automatiquement dans un environnement d’intégration au fur et à mesure des changements enregistrés sur le référentiel de code (Git, généralement). Cela permet d’assurer de manière très lisible la qualité et la non-régression du code, et in fine la qualité de la livraison du logiciel développé.

Dans la plupart des cas, il est recommandé de ne pas livrer le code des tests avec le code de l’applicatif lors de son déploiement par gain de place, sécurité et obfuscation du fonctionnement d’un projet. Il arrive cependant que certaines bibliothèques externes livrent leurs tests dans leurs paquets par soucis de documentation à destination de leurs utilisateurs et pour leur permettre de relancer une suite de test complète en cas de modifications de la bibliothèque.
On peut considérer que les fonctionnalités du langage de programmation utilisé (bibliothèque standard, types primitifs, etc.) comme déjà testées et ne devant pas être re-testées dans un projet. On considère également les bibliothèques externes utilisées dans un projet logiciel comme stables et testées dans leurs dépôts respectifs. Par conséquent, seul le code du projet en développement doit être testé. À ce titre, il est préférable de choisir des bibliothèques externes déjà éprouvées et déjà testées avec une qualité des tests satisfaisante pour assurer la stabilité d’un projet.

Le taux de couverture de test d’une bibliothèque externe est dans la plupart des cas consultable directement dans le README du dépôt Git de la lib ou sur la page descriptive hébergée sur les bases de données de paquets publiques (npmjs, pypi, …).

📘 Développer des tests automatisés

1. Rôle et usage des frameworks de test

1.1. Difficultés du test automatisé

1.2. Notion de framework de test

2. Zoom sur JUnit

2.1. Présentation

2.2. Utiliser Jupiter, la bibliothèque JUnit

2.2.1. Dépendance via un projet Maven

2.2.2. Déclarer une suite de tests et un scénario de test

2.2.3. Programmer un script de test

2.3. Utiliser l’exécuteur

2.3.1. Entrelacer du code au sein des tests pour éviter les redondances

3. Conseils et bonnes pratiques de développement de tests

3.1. Séparation du code de test

3.1.1. Organisation du code de test unitaire

3.2. Structurer un script de test en Given-When-Then

3.3. Bien implémenter un oracle de test

3.4. Bien nommer les variables contenant les données d’entrée

3.5. Ne jamais utiliser try/catch dans un test

3.6. Isolation et indépendance des tests

3.7. Le test : un outil de documentation du code

3.8. Pour aller plus loin : intégration continue et dépendances externes

3.5. Ne jamais utiliser `try/catch` dans un test