Os dados de teste

Este teste falha. Descubra por quê em dez 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);
}

Impossível. O único detalhe que importa — StatutCommande.EXPEDIEE — está afogado em meio a dezoito valores sem relação com a intenção do teste. E no dia em que um campo for adicionado ao construtor, os oitenta testes construídos sobre esse modelo deixarão de compilar de uma só vez.

Essa é a dívida mais traiçoeira de uma suíte de testes: ela não aparece na cobertura nem no tempo de execução, mas triplica o custo de escrita de cada novo teste e torna cada falha ilegível. Um bom objeto de teste deixa visível o que importa e invisível o que não importa. O restante desta lição mostra como fazer isso e depois trata do segundo problema dos dados de teste: o isolamento entre testes, em que as soluções fáceis escondem compromissos que é preciso conhecer.