Notre approche pragmatique des tests automatisés sur des projets clients à délais courts.
Sur des projets avec des délais serrés, la tentation de réduire la couverture de tests est forte. Nous y avons cédé par le passé — et nous avons payé le prix des régressions en production. Voici comment nous avons recalibré notre approche pour tester efficacement sans créer de friction dans l'équipe.
Nous avons identifié trois catégories non négociables : les logiques métier critiques (calculs de prix, règles d'éligibilité, permissions), les intégrations externes (APIs de paiement, webhooks entrants), et les flux utilisateur principaux (connexion, achat, soumission de formulaire). Sur ces trois catégories, nous exigeons une couverture quasi complète. Sur tout le reste, nous appliquons le jugement.
Nous privilégions les tests d'intégration sur les tests unitaires purs. Un test qui simule une vraie requête HTTP, touche la base de données de test et vérifie la réponse est plus proche de la réalité qu'un test qui mocke tout. Nous utilisons Vitest pour le backend Node.js et Playwright pour les flux E2E critiques.
“Un test qui mocke tout ne vous apprend rien sur votre système. Il vous apprend juste que votre mock fonctionne.”
La clé pour ne pas ralentir l'équipe : les tests doivent tourner en moins de deux minutes en CI. Au-delà, les développeurs commencent à les ignorer. Si un test est lent, il faut soit l'optimiser, soit le déplacer dans une suite de tests nocturnes.