Los datos de prueba

Este test falla. Descubre por qué en diez segundos:

@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);
}

Imposible. El único detalle que importa, StatutCommande.EXPEDIEE, queda ahogado entre dieciocho valores que no tienen nada que ver con la intención del test. Y el día que se añade un campo al constructor, los ochenta tests construidos sobre este modelo dejan de compilar de golpe.

Es la deuda más insidiosa de una suite de tests: no aparece ni en la cobertura ni en el tiempo de ejecución, pero multiplica por tres el coste de escribir cada nuevo test y hace ilegible cada fallo. Un buen objeto de prueba hace visible lo que importa e invisible lo que no. El resto de esta lección muestra cómo conseguirlo y después aborda el segundo problema de los datos de prueba: el aislamiento entre tests, donde las soluciones fáciles esconden compromisos que conviene conocer.