Tester sans souffrir

Un bon test vous rassure. Un mauvais test vous ralentit.

Pourquoi tester ?

• Refactoriser sans trembler
• Documenter le comportement attendu
• Détecter les régressions tôt
• Déployer avec confiance

La pyramide

flowchart TB
  A["End-to-end : peu, lents, réalistes"]
  B["Intégration : quelques-uns"]
  C["Unitaires : nombreux, rapides"]
  A --- B --- C

Plus on monte, plus c'est réaliste, mais lent et fragile.

Que tester ?

Structure d'un test : AAA

it("calcule le total avec remise", () => {
  // Arrange
  const panier = creerPanier([{ prix: 100 }]);

  // Act
  const total = panier.total({ remise: 0.1 });

  // Assert
  expect(total).toBe(90);
});

Préparer, agir, vérifier.

Tester le comportement

// ❌ Teste l'implémentation
expect(composant.state.ouvert).toBe(true);

// ✅ Teste ce que voit l'utilisateur
await user.click(screen.getByRole("button", { name: "Ouvrir" }));
expect(screen.getByRole("dialog")).toBeVisible();

Un test qui survit à un refactoring est un bon test.

Les tests instables

Causes fréquentes :

• Attentes basées sur des délais fixes
• Interaction avec un composant non hydraté
• Dépendance à l'heure ou à l'ordre d'exécution

Remède : attendre une condition, jamais une durée.

La couverture

• Un indicateur, pas un objectif
• 100 % ne garantit pas l'absence de bug
• Un seuil évite surtout la dérive silencieuse

À retenir

1. Beaucoup d'unitaires, peu d'e2e ciblés
2. Testez ce que l'utilisateur voit
3. Un test instable est pire que pas de test