Les tests automatisés semblent coûteux à mettre en place. Ils le sont, mais infiniment moins que l'absence de tests. Un bug trouvé en développement coûte 1x. En production, il coûte 100x.
Le premier argument contre les tests automatisés est toujours le même : on n'a pas le temps. Écrire des tests prend du temps, les maintenir aussi. C'est vrai. Ce qui est faux, c'est de croire que ne pas tester est gratuit. L'absence de tests a un coût — il est simplement différé et multiplié.
La pyramide des tests
Mike Cohn a formalisé la pyramide des tests : une large base de tests unitaires (rapides, isolés, nombreux), une couche intermédiaire de tests d'intégration (vérifient l'interaction entre composants), et une pointe de tests E2E (end-to-end, simulant l'utilisateur réel). Plus on monte dans la pyramide, plus les tests sont lents, fragiles et coûteux à maintenir. La pyramide, c'est la règle d'équilibre.
Le coût d'un bug selon où il est trouvé
Les études du NIST et d'IBM le documentent depuis les années 1990 : un bug trouvé en développement coûte ~1x. En staging : ~10x. En production : ~100x. Le coût inclut le temps de diagnostic, le rollback éventuel, la communication de crise, la perte de confiance client, et parfois des pertes commerciales directes. Les tests ne sont pas un coût — ils sont une assurance.
Types de tests et outils
- Unitaires : JUnit (Java), Jest (JS/TS), pytest (Python) — testent une fonction ou une classe isolément
- Intégration : Testcontainers, Supertest — testent l'interaction avec la base de données, les APIs
- E2E : Playwright, Cypress — simulent le parcours utilisateur dans le navigateur
- Contrat : Pact — vérifient que deux services respectent leur contrat d'interface
- Performance : Gatling, k6 — testent la tenue en charge
TDD : tester avant de coder
Le Test-Driven Development inverse l'ordre : on écrit le test avant le code. Bénéfice principal : les tests deviennent un outil de conception. On réfléchit à l'interface avant à l'implémentation. Le code produit est naturellement plus modulaire et testable. Le taux de couverture ? Un indicateur utile, mais souvent mal utilisé : 100% de couverture ne garantit pas l'absence de bugs — cela garantit que chaque ligne a été exécutée.