TDD en Java à partir de zéro : comment les tests changent le code et sauvent les nerfs

Pourquoi le TDD n'est pas une question « d'écrire des tests », mais de « penser différemment »

Imaginez que vous construisez une maison. Vous avez des plans, des matériaux et une équipe. Mais vous commencez à poser des briques sans avoir vérifié les fondations. Un mois plus tard, vous découvrez que les murs se fissurent. Cela vous dit quelque chose ? En programmation, on appelle cela « on corrigera plus tard ». Et « plus tard » arrive généralement à 3 heures du matin avant le déploiement.

Le développement piloté par les tests (TDD — Test-Driven Development) est une technique qui bouleverse le processus. Vous n'écrivez pas d'abord le code, puis les tests. Vous écrivez d'abord le test — et ensuite seulement le code qui fait passer ce test. Cela semble fou ? En pratique, cela fait gagner des heures, préserve les nerfs et rend le code plus propre que l'air du matin à la montagne.

Dans cet article, nous allons analyser le TDD en Java avec des exemples concrets. Pas de blabla — seulement du code, le cycle Red-Green-Refactor et des scénarios réels. C'est parti.

Qu'est-ce que le TDD et comment fonctionne le cycle Red-Green-Refactor

Le TDD repose sur trois étapes simples, répétées de manière cyclique :

\n
• Red — nous écrivons un test qui échoue (il doit planter).
\n
• Green — nous écrivons le code minimal pour que le test réussisse.
\n
• Refactor — nous améliorons le code sans changer son comportement. Les tests restent verts.
\n

Cela semble ralentir le développement. En réalité, cela l'accélère. Vous arrêtez de vous demander « est-ce que ça marche ? ». Vous le savez : ça marche, parce que le test est vert.

Les principes clés du TDD

\n
• N'écrivez pas une ligne de code de production sans test.
\n
• Le test doit être le plus simple possible et vérifier exactement un comportement.
\n
• Le code est écrit juste assez pour que le test réussisse. Pas de « et si on ajoutait ça au cas où ».
\n

Passons maintenant à Java et JUnit 5 — le framework le plus populaire pour les tests unitaires.

Configuration du projet : Maven, JUnit 5 et structure

Pour les exemples, nous utiliserons Maven. Ajoutez la dépendance dans pom.xml :

<dependency>\n    <groupId>org.junit.jupiter</groupId>\n    <artifactId>junit-jupiter-api</artifactId>\n    <version>5.10.0</version>\n    <scope>test</scope>\n</dependency>

La structure des dossiers est standard pour Maven :

src/\n  main/java/com/example/\n  test/java/com/example/

Toutes les classes de test sont placées dans src/test/java. Le nom de la classe de test correspond généralement au nom de la classe testée, suivi du suffixe Test. Par exemple, Calculator → CalculatorTest.

Premier cycle TDD : créer une calculatrice à partir de zéro

Objectif : créer une méthode add(int a, int b) qui retourne la somme. Avec le TDD, on ne commence pas par la classe, mais par le test.

Étape 1 : Red — écrire un test qui échoue

import org.junit.jupiter.api.Test;\nimport static org.junit.jupiter.api.Assertions.*;\n\npublic class CalculatorTest {\n\n    @Test\n    void shouldAddTwoNumbers() {\n        Calculator calc = new Calculator();\n        int result = calc.add(2, 3);\n        assertEquals(5, result);\n    }\n}

On essaie de lancer le test — le compilateur se plaint : la classe Calculator n'existe pas. Parfait, le feu rouge est allumé.

Étape 2 : Green — écrire le code minimal

Créons la classe Calculator avec une méthode qui retourne simplement la somme :

public class Calculator {\n    public int add(int a, int b) {\n        return a + b;\n    }\n}

Lançons le test — vert. L'implémentation minimale a fonctionné.

Étape 3 : Refactor

À ce stade, le code est déjà simple, il n'y a rien à refactoriser. Mais imaginons que nous voulions renommer la méthode ou ajouter une vérification de dépassement de capacité. Nous le faisons, et le test passe toujours. Si quelque chose se casse — le test échouera et indiquera immédiatement le problème.

Compl