Tous les types de tests n'ont pas leur place à toutes les étapes de la CI. La pyramide de tests est un guide pour équilibrer vitesse et confiance dans votre pipeline.
La pyramide de tests de Mike Cohn reste la meilleure boussole pour organiser sa stratégie de test en CI. À la base : les tests unitaires, nombreux, rapides, isolés. Au milieu : les tests d'intégration, moins nombreux, vérifiant que les composants fonctionnent bien ensemble. Au sommet : les tests E2E (end-to-end), peu nombreux, lents, vérifiant les flux utilisateur critiques. L'erreur la plus commune est d'inverser la pyramide : beaucoup de tests E2E fragiles, peu de tests unitaires fiables.
La pyramide de Mike Cohn : plus on monte, plus les tests sont lents, coûteux et peu nombreux.
Les tests unitaires doivent tourner dans la CI à chaque push, sans délai. Ils ne doivent pas dépendre de la base de données, du réseau ou du système de fichiers. En Java, JUnit 5 + Mockito ; en JavaScript, Jest ou Vitest. Les tests d'intégration vérifient les interactions réelles — l'ORM avec une vraie base de données (Testcontainers en Java est excellent pour ça), les appels HTTP à des APIs mockées. Ils sont plus lents mais restent gérables en CI si bien isolés.
Les tests E2E avec Cypress ou Playwright sont les plus fragiles et les plus coûteux à maintenir. Réservez-les aux flux critiques : login, paiement, flux principal. Faites-les tourner uniquement avant un déploiement en production, pas sur chaque PR. La gestion des tests flaky est un travail en soi : trackez le taux de succès de chaque test, mettez en quarantaine les flaky tests, fixez-les avant de les réintégrer.
- Gardez les tests unitaires rapides et indépendants
- Utilisez Testcontainers pour les tests d'intégration avec vrais services
- Réservez les tests E2E aux flux critiques
- Traitez les tests flaky comme des bugs prioritaires
→ À lire aussi : Bonnes pratiques CI/CD · ROI des tests automatisés