Les données de test

Ce test échoue. Trouvez pourquoi en dix secondes :

@Test
void une_commande_expediee_ne_peut_plus_etre_annulee() {
    Client client = new Client(1L, "Alice", "alice@example.com", "12 rue des Lilas",
                               "75011", "Paris", "FR", true, false, null,
                               LocalDate.of(2024, 1, 1), Statut.ACTIF, 0, null);
    Commande commande = new Commande(10L, client, List.of(
        new Ligne(1L, "REF-1", 2, new BigDecimal("19.99"), new BigDecimal("0.20"))),
        LocalDateTime.now(), StatutCommande.EXPEDIEE, null, null, "FR", false);

    assertThatThrownBy(() -> service.annuler(commande)).isInstanceOf(CommandeExpedieeException.class);
}

Impossible. Le seul détail qui compte — StatutCommande.EXPEDIEE — est noyé au milieu de dix-huit valeurs sans rapport avec l'intention du test. Et le jour où un champ est ajouté au constructeur, les quatre-vingts tests bâtis sur ce modèle cessent de compiler d'un coup.

C'est la dette la plus sournoise d'une suite de tests : elle n'apparaît ni dans la couverture, ni dans la durée d'exécution, mais elle multiplie par trois le coût d'écriture de chaque nouveau test et rend chaque échec illisible. Un bon objet de test rend visible ce qui compte et invisible ce qui ne compte pas. Le reste de cette leçon montre comment, puis traite le second problème des données de test : l'isolation entre tests, où les solutions faciles cachent des compromis qu'il faut connaître.