COMPLÉMENT : TP TESTS QUI ÉCHOUENT VOLONTAIREMENT PUIS PASSENT

Objectif :

désacraliser les tests, montrer qu’un test guide le développement et comprendre que l’échec est normal et utile !

---

Philosophie du TP

En Java :

• on écrit le test
• il échoue
• on écrit le code

• il passe… ouf !

• Ce n’est pas une contrainte,
• c’est un outil de sécurisation.

---

Principe : le cycle TDD (sans le nommer)

1. J’écris un test
2. Le test échoue
3. J’écris le minimum de code
4. Le test passe
5. Je refactorise si nécessaire

---

TP : Écrire un test AVANT le code

Contexte métier

Nouvelle règle métier :

“Un virement ne peut pas être effectué si le montant est négatif.”

• Cette règle n’existe pas encore dans le code.

---

Étape 1 – Écrire le test (et accepter qu’il échoue)

Vous êtes libre d’utiliser des Double ou double plutôt que le BigDecimal pour simplifier les TP.

Test (à écrire en premier)

Une méthode de test :

@Test
void virement_refuse_si_montant_negatif() {
    Compte source = new CompteCourant(
        "FR001", new BigDecimal("1000"), new BigDecimal("500"));
    Compte cible = new CompteEpargne(
        "FR002", new BigDecimal("300"));

    VirementService service = new VirementService();

    assertThrows(
        IllegalArgumentException.class, () -> service.virer(source, cible, new BigDecimal("-100"))
    );
}

---

Résultat attendu

Le test échoue et c’est normal !

Messages possibles :

• méthode inexistante
• exception non levée
• comportement non implémenté

C’est le point de départ, pas une erreur.

---

Étape 2 – Implémenter un minimum de code

Code métier initial (à corriger)

public class VirementService {

    public void virer(Compte source, Compte cible, BigDecimal montant) {
        source.debiter(montant);
        cible.crediter(montant);
    }
}

---

Étape 3 – Faire passer le test

Code corrigé

public void virer(Compte source, Compte cible, BigDecimal montant) {
    if (montant.compareTo(BigDecimal.ZERO) <= 0) {
        throw new IllegalArgumentException("Montant invalide");
    }
    source.debiter(montant);
    cible.crediter(montant);
}

---

Étape 4 – Relancer le test

• Le test passe
• La règle métier est sécurisée
• Le comportement est documenté

---

Discussion

Questions à se poser :

• Aviez-vous confiance dans le code AVANT le test ?
• Le test a-t-il clarifié la règle métier ?
• Que se passerait-il si quelqu’un supprimait ce contrôle plus tard ?
• Le test protège-t-il le métier ?

---

Erreurs à éviter (TP échouant)

1. Corriger le test au lieu du code
2. Supprimer le test parce qu’il échoue
3. Ajouter trop de logique d’un coup
4. Tester plusieurs règles à la fois
5. Ne pas lire le message d’erreur
6. Penser que “test = perte de temps”

---

Conclusion

À ce stade, les développeurs et les développeuses comprennent que :

• un test qui échoue est normal
• un test qui passe est une garantie
• le test devient un allié
• la peur des tests disparaît

Vous êtes bientôt prêt pour aborder Spring Boot.

---