TDD — Du cycle à la pratique quotidienne

Le Test-Driven Development ne se limite pas à écrire un test avant le code. C’est un cadre de design itératif qui transforme le développement en dialogue permanent entre l’API prévue et l’implémentation.

Cette page suppose une maîtrise de JUnit 5 et Mockito. Pour les patterns de test JVM, voir JUnit 5 & Mockito.

Le cycle complet illustré

Sujet

Implémenter la validation d’un code promotionnel (10 % de réduction si le panier dépasse 50 €).

1. Red — le test échoue

Le test doit vérifiablement échouer. Trois signes de validité :

Signe	Ce que ça veut dire
Erreur de compilation	La méthode/fonction n’existe pas
Assertion fausse	Le comportement attendu diverge de la réalité
Timeout	La méthode tourne en boucle (note : attendre d’écrire le code, la plupart du temps)

Si aucun de ces signes ne se produit, le test ne teste rien.


@Test
void codeValideApplique10PourCentSiPanierPlusDe50() {
    var code = new CodePromotion("ETE10", 10,
        new Regle().minPanier().superieurA(50));
    var panier = new Panier(BigDecimal.valueOf(60));
    var discount = code.appliquer(panier);
 
    assertEquals(6.0, discount.valeur(), 0.01);
}

CodePromotion, Regle, Panier, discount n’existent pas — le test ne compile pas. Premiers changements pour le faire compiler (faker le minimum) :


class CodePromotion {
    public Decote appliquer(Panier panier) {
        return new Decote(0.0);
    }
}

2. Green — le code minimal

Écrire strictement le minimum pour que le test passe. Pas de cas supplémentaires, pas de refactor.


public Decote appliquer(Panier panier) {
    if (panier.total().compareTo(BigDecimal.valueOf(50)) > 0) {
        return new Decote(panier.total().multiply(BigDecimal.valueOf(0.10)).doubleValue());
    }
    return new Decote(0.0);
}

Test vert. Premièrement terminé.

3. Refactor — nettoyer avec confiance

Ajouter un second test couvrant le cas “panier inférieur à 50 ” :


@Test
void codeInvalideRetourne0() {
    var code = new CodePromotion("ETE10", 10,
        new Regle().minPanier().superieurA(50));
    var panier = new Panier(BigDecimal.valueOf(30));
    var discount = code.appliquer(panier);
 
    assertEquals(0.0, discount.valeur(), 0.01);
}

Le refactor peut maintenant séparer la logique de décision :


public Decote appliquer(Panier panier) {
    return regle.satisfait(panier)
        ? new Decote(panier.total().multiply(ratio).doubleValue())
        : new Decote(0.0);
}

Tous les tests verts. Le design est meilleur, aucune régression.

Règle d’or

Si le refactor pose un doute, écrire d’abord un test qui capture le comportement actuel, puis refactorer. Le test est le filet de sécurité.

State-based vs behavior-based

Le choix de stratégie d’assertion impacte directement la robustesse des tests.

State-based

Vérifie l’état final de l’objet testé : un return value, un objet modifié, une exception lancée.


@Test
void panierVideRetourneZero() {
    Panier panier = new Panier();
    assertEquals(BigDecimal.ZERO, panier.total());
}

Avantages : simple, rapide, indépendant du contexte. Inconvénient : ne vérifie pas comment l’état est atteint.

Behavior-based

Vérifie les interactions avec les dépendances : méthode appelée avec quels arguments, nombre d’appels.


@Test
void confirmerEnvoieEmailConfirmation() {
    var repository = mock(PanierRepository.class);
    var notificateur = mock(Notificateur.class);
    var service = new ServicePanier(repository, notificateur);
 
    service.confirmer(new Panier(1L));
 
    verify(notificateur).envoyerEmail(eq("confirmation"));
}

Avantages : détecte les régressions de logique interne. Inconvénient : peut devenir fragile si le comportement interne change sans changer la sémantique.

Guide de décision

Situation	Stratégie
Méthode pure (sans effets de bord)	State-based
Méthode qui modifie un objet/fichier/base	State-based
Méthode qui déclenche un envoi, un flush, un hook	Behavior-based
Méthode qui combine les deux	State-based prioritaire, behavior-based en complément

Hiérarchie des doubles légers

Type	Rôle	Exemple concret
Dummy	Objet passé sans jamais être utilisé	Paramètre requis par le constructeur (ex. `UUID.randomUUID()`)
Stub	Répond à des appels avec des valeurs prédéfinies	`return List.of(p);`
Fake	Implémentation simplifiée mais fonctionnelle	`MapPanier` au lieu de `PanierRepository` persistant
Spy	Objet réel qui enregistre les appels	`Mockito.spy(logger)`
Mock	Double prédressé avec des attentes de comportement	`verify(service).envoyerEmail(...)`

Exemple : naissance progressive du test


class ServicePanierTest {
 
    @Test
    void calculerLivraisonReussie() {
        // Dummy — l'adresse est requise mais pas lue dans ce test
        Adresse dummy = new Adresse("10", "Rue X", "75001", "FR");
        Panier panier = new Panier(dummy);
        panier.ajouter(new Ligne(new Produit("A"), 2));
 
        var resultat = panier.livraison();
 
        assertNotNull(resultat);
    }
 
    @Test
    void calculerLivraisonZoneFranceMetropolitaine() {
        // Stub — le calculateur de frais renvoie une valeur fixe
        CalculateurFrais calculateur = Mockito.mock(CalculateurFrais.class);
        when(calculateur.frais("FR")).thenReturn(5.5);
 
        var service = new ServicePanier(calculateur);
        var frais = service.calculerFrais("FR", BigDecimal.TEN);
 
        assertEquals(5.5, frais.doubleValue(), 0.01);
    }
 
    @Test
    void livraisonAvecFakePanier() {
        // Fake — map en mémoire qui implémente PanierRepository
        PanierRepository fake = new PanierRepositoryInMemory();
        fake.sauvegarder(new Panier(1L, "Alice"));
 
        var service = new ServicePanier(fake);
        var panier = service.obtenir(1L);
 
        assertEquals("Alice", panier.client().nom());
    }
 
    @Test
    void sauvegarderAppeleRepository() {
        PanierRepository repo = Mockito.mock(PanierRepository.class);
        var service = new ServicePanier(repo);
        var panier = new Panier("Bob");
 
        service.sauvegarder(panier);
 
        verify(repo).sauvegarder(argThat(p -> p.client().nom().equals("Bob")));
    }
}

Piège courant : mock sur-le-gon

@ExtendWith(MockitoExtension.class) injecte des @Mock actifs. Créer un mock dans le corps du test (au lieu de l’injecter) lève des erreurs silencieuses sur les méthodes non-stubbing :


// ❌ Mauvais : le mock n'est pas initialisé par MockitoExtension
var repo = new Mock().for(PanierRepository.class);

TDD sur du code legacy

Test-and-modify (truffle testing)

Avant de toucher la logique, capter le comportement actuel :


// 1. Observer le comportement actuel du code existant
// (souvent via un vrai appel intégration)
 
// 2. Écrire un test qui l'capture
@Test
void creerPanierPourClientExistantRetourne201() throws Exception {
    mockMvc.perform(post("/api/paniers")
            .contentType(MediaType.APPLICATION_JSON)
            .content("""
                {"client":"C123","articles":[{"id":"A","qty":1}]}
                """
            ))
        .andExpect(status().isCreated());
}

Une fois ce test vert obtenu, on peut refactorer le code existant avec confiance.

Strangler Fig

Remplacer progressivement le legacy :

Créer un satellite avec un point d’entrée contrôlé par le legacy.
Écrire la nouvelle implémentation par TDD sous le satellite.
Rediriger le traffic graduellement depuis le satellite vers le nouveau service.
Supprimer le satellite quand tout est migré.


                   ┌─[Legacy Service]──────────────────┐
                   │                                    │
[Client] ────▶ [API Gateway] ───▶ [Legacy Controller]  │
                   │               ▲                    │
                   │   décide selon la ressource        │
                   │                                    │
                   │               ▼                    │
                   │  ┌─[New Service]──────────────────┐│
                   │  │  Bâti par TDD                   ││
                   │  │  Testé unitairement & intégré   ││
                   │  └────────────────────────────────┘│
                   └────────────────────────────────────┘

Piège du mock excessif

Mocker la couche métier retire la protection du TDD : si on mock tout ce qui est testé, le vert ne signifie plus grand chose.

Exception : les interactions avec des systèmes externes (Stripe, microservice tiers). Les mocks ici isolent les tests, pas le code métier.

Quand TDD n’est PAS adapté

Contexte	Pourquoi le TDD est contre-productif
Exploration / spike	Le but est d’apprendre, pas de produire du code stable
Proof-of-concept	Le code est jetable ; les tests deviennent du code mort
Scripting / automation ponctuelle	Un petit script bash/Python a une durée de vie limitée
Re-reading un code existant	Passer du temps à écrire des tests pour du code qu’on ne touchera plus
Contrôleurs 1-liner	Le test colle au framework, pas à la logique métier

Approche alternative : TDD light

Pour les cas où le TDD complet est trop lourd, la variante TDD light conserve seulement la boucle :

Un test unitaire sur la fonction métier.
Pas de test sur les contrôleurs (gérés par Testcontainers ou intégration légère).
Pas de red/green/refactor parfait — écrire les tests avant le code constitue déjà un niveau nettement supérieur à l’absence de tests.

Garder la boucle courte

La valeur du TDD diminue avec la vitesse de la boucle. Objectif : passer du rouge au vert en moins de 2 minutes.

Outils de mesure

Outil	Usage
`pt` (parakeet)	Mesure du temps de chaque test, déclenche un avertissement si > 2s
`mvn test -pl :module`	Lancer uniquement le module de travail
Verrouillage de segment	`grep -n` dans les fichiers pertinents uniquement

Naming et découpage

Un test lisible guide le refactor :


// ✅ Découpage fonctionnel + préfixe de classe comme catégorie
// PanierTest.TestSiInscription → isolé des autres catégories
 
@Test
void totalVideValideZero() {
    var panier = new Panier();
    assertEquals(0.0, panier.total().doubleValue(), 0.01);
}

Structure de noms :

Convention	Exemple
`test_methodeCondition_attendu()`	`test_avecCodeRecharge____100Points()`
`Given_When_Then()` en méthode light	Lorsqu’un test fait beaucoup de setups

Organiser les fichiers de test


src/test/java/com/maison/app/
├── service/
│   ├── ServicePanierTest.java          ← tests "snappy"
│   ├── ServicePanierIntegrationTest.java ← avec Testcontainers
│   └── ServicePanierValidationsTest.java ← instancié par @Nested
├── controller/
│   └── PanierControllerTest.java
└── tdd/                                ← exemples TDD optionnels
    └── TddCycleIllustrationTest.java

Résumé

Écrire un test qui échoue pour trois raisons validées.
Écrire le code minimum pour passer.
Refactorer sans peur, les tests protègent.
Choisir state-based ou behavior-based selon le périmètre.
Sur du legacy : capturer d’abord, déplacer ensuite.
Garder la boucle sous 2 minutes pour garder le rythme.