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
Taxonomie des Types de Tests
│
├── Tests Unitaires
│ ├── Tests de fonctions pures (sans dependances)
│ ├── Tests de composants (module unique avec mocks)
│ └── Tests de snapshot (sortie composant UI)
│
├── Tests d'Intégration
│ ├── Intégration service (API + base de données)
│ ├── Tests de contrat (cote consommateur ou fournisseur)
│ └── Intégration composant (module + dependances reelles)
│
├── Tests de Bout en Bout
│ ├── Pilotes par UI (Playwright, Cypress)
│ ├── Pilotes par API (flux requete complet)
│ └── Monitoring synthétique (sondes production)
│
├── Tests Specialises
│ ├── Property-based (entrees generatives)
│ ├── Tests de mutation (modification du code)
│ ├── Tests de chaos (injection de pannes)
│ ├── Tests de performance / charge
│ └── Tests de regression visuelle
│
└── Tests en Production
├── Déploiements canary
├── Feature flags + tests A/B
└── Monitoring synthétique
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
┌────────────────────────────────────────────────────────┐
│ ETAPE 1 : PRE-COMMIT (< 30 secondes) │
│ Linting, formatage, type checking, tests affectes │
├────────────────────────────────────────────────────────┤
│ ETAPE 2 : PIPELINE CI (< 10 minutes) │
│ Suite unitaire, intégration, contrats, SAST, build │
├────────────────────────────────────────────────────────┤
│ ETAPE 3 : DEPLOIEMENT STAGING (< 30 minutes) │
│ Deployer staging, E2E, performance, regression, DAST │
├────────────────────────────────────────────────────────┤
│ ETAPE 4 : PRODUCTION (continu) │
│ Canary, monitoring synthétique, rollback automatique │
└────────────────────────────────────────────────────────┘
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