Stratégies de Test Modernes : Au-delà de la Pyramide de Tests
#testing#devops#ci-cd#architecture#quality
La pyramide de tests -- tests unitaires a la base, intégration au milieu, bout en bout au sommet -- nous a bien servi pendant une decennie. Mais les architectures modernes (microservices, systèmes événementiels, serverless) ont expose ses limites. De nouveaux modèles comme le diamant de tests, le trophee de tests et le contract testing sont apparus pour combler les lacunes.
Taxonomie des Types de Tests
tadata
- Tests unitaires
- Tests de fonctions pures (sans dépendances)
- Tests de composants (module unique avec mocks)
- Tests de snapshot (rendu d'un composant UI)
- Tests d'intégration
- Intégration de service (API + base de données)
- Tests de contrat (pilotés par le consommateur ou le fournisseur)
- Intégration de composant (module + dépendances réelles)
- Tests de bout en bout
- Pilotés par l'UI (Playwright, Cypress)
- Pilotés par l'API (flux de requête complet)
- Monitoring synthétique (sondes en production)
- Tests spécialisés
- Property-based (entrées générées)
- Tests de mutation (modification du code)
- Tests de chaos (injection de pannes)
- Tests de performance / charge
- Tests de sécurité (DAST, SAST)
- Tests de régression visuelle
- Tests en production
- Déploiements canary
- Feature flags + tests A/B
- Monitoring synthétique
- Tests pilotés par l'observabilité
Comparaison des Stratégies : Pyramide vs Diamant vs Trophee
| Aspect | Pyramide | Diamant | Trophee |
|---|---|---|---|
| Accent | Tests unitaires dominent | Tests d'intégration dominent | Intégration + analyse statique |
| Ratio unitaires | 70% | 20-30% | 20-30% |
| Ratio intégration | 20% | 50-60% | 40-50% |
| Ratio E2E | 10% | 10-20% | 10% |
| Analyse statique | Non prioritaire | Non prioritaire | Couche fondation |
| Vitesse | Plus rapide globalement | Moderee | Moderee |
| Confiance | Elevee pour logique isolée | Elevee pour comportement système | Elevee pour comportement utilisateur |
| Cout maintenance | Faible (unitaires), élevé (E2E) | Modere | Modere |
| Architecture ideale | Monolithe, librairies | Microservices, APIs | Frontend, full-stack JS |
Paysage d'Outils par Type de Test
| Type de Test | JavaScript/TS | Python | Go | Cross-Platform |
|---|---|---|---|---|
| Unitaire | Vitest, Jest | pytest | go test | -- |
| Intégration | Supertest, Testcontainers | pytest + httpx | testcontainers-go | Testcontainers |
| E2E (UI) | Playwright, Cypress | Playwright | -- | Playwright |
| Contrat | Pact JS | Pact Python | Pact Go | Pact |
| Property-based | fast-check | Hypothesis | rapid | -- |
| Mutation | Stryker | mutmut | -- | -- |
| Performance | k6, Artillery | Locust | vegeta | k6 |
| Analyse statique | ESLint, TypeScript | mypy, ruff | go vet | SonarQube |
Architecture d'Intégration CI/CD
tadata
- 1. Push du développeur
- 2. Pre-commit (< 30 s)
- 3. Pipeline CI (< 10 min)
- 4. Déploiement staging (< 30 min)
- 5. Production (en continu)
- Pre-commit (< 30 s)
- linting (ESLint, ruff), formatage (Prettier, black), vérification de types (TypeScript, mypy), uniquement les tests unitaires concernés
- Pipeline CI (< 10 min)
- suite complète de tests unitaires, tests d'intégration (Testcontainers), tests de contrat (broker Pact), analyse de sécurité (SAST), artefacts de build
- Déploiement staging (< 30 min)
- déploiement en staging, tests E2E (Playwright sur staging), tests de performance de référence, tests de régression visuelle, analyse de sécurité (DAST)
- Production (en continu)
- déploiement canary (5 % → 25 % → 100 %), monitoring synthétique, suivi du taux d'erreur, rollback automatique en cas de violation de SLO
tadata
Extrait de la fiche « AZ-400 Domain 3b: Packages, Testing and Release Strategies » · Demander la fiche complète
Cout du Defaut par Etape
| Étape de Détection | Cout Relatif | Exemple | Méthode de Détection |
|---|---|---|---|
| Conception / planification | 1x | Exigence mal comprise | Revue de conception |
| Codage (IDE) | 1.5x | Erreur de type, référence nulle | Analyse statique, système de types |
| Pre-commit | 2x | Erreur logique dans une fonction | Test unitaire, linting |
| Pipeline CI | 5x | Contrat d'intégration casse | Test intégration, test contrat |
| Staging / QA | 15x | Flux utilisateur casse | Test E2E, QA manuelle |
| Production (détecté vite) | 50x | Corruption données, panne | Monitoring, tests synthétiques |
| Production (détecté tard) | 100-1000x | Corruption silencieuse, non-conformité | Audit, rapport client |
Contract Testing en Detail
| Aspect | Consumer-Driven (Pact) | Provider-Driven | Base sur Schema (OpenAPI) |
|---|---|---|---|
| Qui definit le contrat ? | Consommateur | Fournisseur | Specification partagée |
| Direction de vérification | Consommateur généré, fournisseur vérifié | Fournisseur publié, consommateurs s'adaptent | Les deux valident contre la spec |
| Ideal pour | Microservices avec consommateurs connus | APIs publiques | Développement API-first |
| Détection de derive | Excellente | Bonne | Bonne (si appliquee) |
| Outils | Pact, PactFlow | Spring Cloud Contract | Spectral, Optic, Prism |
Property-Based Testing : Quand et Pourquoi
| Scenario | Exemple de Propriété | Faiblesse du Test Traditionnel |
|---|---|---|
| Aller-retour serialisation | decode(encode(x)) == x | Ne testé que des exemples choisis |
| Tri | Sortie triée ET même longueur | Rate les cas limités (vidé, doublons) |
| Validation entrées API | Aucune entrée ne fait crasher le serveur | Ne testé que le happy path |
| Machines a états | Toutes les transitions maintiennent les invariants | Explosion combinatoire |
Ressources
- Software Engineering at Google - Chapitre Testing -- philosophie de test Google
- Testing JavaScript (Kent C. Dodds) -- origine du trophee de tests
- Contract Testing with Pact -- documentation officielle Pact
- Hypothesis (Property-Based Testing Python) -- référence du property-based testing
- Documentation Playwright -- framework de test E2E moderne