“Le mauvais chasseur, il voit un truc qui bouge, il tire. Le bon chasseur, il voit un truc qui bouge, il tire… mais c’est un bon chasseur.”
Le mauvais test, il assert un truc, il passe au vert. Le bon test, il assert un truc, il passe au vert… mais c’est un bon test.
- Concrètement, qu’est-ce qui sépare les deux ?
- Pourquoi certaines suites de tests deviennent un harnais qui permet de refactorer en confiance, et d’autres un boulet qu’on désactive au premier sprint chargé ?
La promesse
Une vraie base de code : les chasseurs du Bouchonnois et leurs parties de chasse aux galinettes qu’on va reprendre ensemble.
À chaque chapitre, un symptôme, un diagnostic, un remède.
- Chapitre 1 : Le bon test ne ment pas.
Mutation testing : faire la chasse aux assertions qui passent toujours, parce que “never trust a test you haven’t seen fail”. - Chapitre 2 : Le bon test, on le lit.
Test Data Builders, Object Mothers, custom assertions, DSL Given/When/Then : transformer un test de 30 lignes en spec métier lisible en 5 secondes. - Chapitre 3 : Le bon test, on le maintient.
SRP, DRY, hiérarchie de classes : les principes Clean Code s’appliquent aux tests autant qu’au code de prod. - Chapitre 4 : Le bon test, parfois, ne s’écrit pas à la main.
Approval Testing pour les scénarios à grosses assertions et ses pièges. - Chapitre 5 : Le bon test couvre ce que tu n’as pas pensé à tester.
Property-Based Testing : une propriété, 100 exécutions, des cas tordus que tu n’aurais jamais imaginés. - Chapitre 6 : Le bon test protège l’architecture.
Tests d’architecture : matérialiser les règles d’oignon, d’hexagonal, de Clean Architecture en tests qui échouent au premier merge incorrect.
Pour qui ?
Développeur·se·s, tech leads, toute personne qui a déjà soupiré devant un fichier de tests de 900 lignes.
Des exemples concrets transposables à tous les langages.
