4 min lecture • Guide 844 of 877
Stratégies de Tests Automatisés
Les stratégies de tests automatisés fournissent un feedback rapide et préviennent les régressions dans le développement. GitScrum aide les équipes à suivre l'exécution des tests et à gérer les workflows de test tout au long du cycle de vie du développement.
Implémentation de la Pyramide de Test
Tests Unitaires (Beaucoup) ──► Tests d'Intégration ──► Tests E2E (Peu)
│ │ │
▼ ▼ ▼
Feedback Rapide Interaction Composants Validation Parcours
La Pyramide en Détail
PYRAMIDE DE TEST
════════════════
▲
/│\ TESTS E2E (UI)
/ │ \ • Parcours utilisateur complets
/ │ \ • Lents mais haute confiance
/───┼───\ • 5-10% des tests
/ │ \
/ │ \ TESTS D'INTÉGRATION
/ │ \ • Interactions entre services
/───────┼───────\ • Vitesse moyenne
/ │ \ • 20-30% des tests
/ │ \
/ │ \ TESTS UNITAIRES
/───────────┼───────────\ • Fonctions isolées
/ │ \• Rapides (ms)
/─────────────┴─────────────\• 60-70% des tests
RÈGLE : Plus on monte, moins de tests mais plus de couverture métier
Workflow d'Automatisation des Tests
Écrire Tests ──► Exécuter en CI ──► Analyser Résultats ──► Corriger Échecs
│ │ │ │
▼ ▼ ▼ ▼
TDD/BDD Exécution Rapports de Prévention
Parallèle Couverture Régression
Composants de la Stratégie de Test
Types de Tests
| Type | Portée | Vitesse | Confiance |
|---|---|---|---|
| Unitaire | Fonction/méthode | ms | Composant isolé |
| Intégration | Service/module | secondes | Interactions |
| API | Contrat/réponse | secondes | Service |
| E2E | Parcours complet | minutes | Système |
| Performance | Charge/stress | minutes | Scalabilité |
| Sécurité | Vulnérabilités | variable | Protection |
Stratégie par Niveau
STRATÉGIE DE TEST MULTICOUCHE
═════════════════════════════
TESTS UNITAIRES :
├── Tester chaque fonction en isolation
├── Mocker les dépendances externes
├── Exécuter sur chaque commit
├── Objectif : > 80% couverture
└── Temps : < 30 secondes total
TESTS D'INTÉGRATION :
├── Tester les interactions composants
├── Utiliser des bases de données de test
├── Exécuter sur chaque PR
├── Objectif : Chemins critiques couverts
└── Temps : < 5 minutes
TESTS E2E :
├── Tester les parcours utilisateur clés
├── Environnement proche de prod
├── Exécuter avant déploiement
├── Objectif : Parcours métier critiques
└── Temps : < 15 minutes
Intégration CI/CD
Pipeline de Test
PIPELINE CI/CD AVEC TESTS
═════════════════════════
Commit Push
│
▼
┌─────────────┐
│ Linting │ ← Qualité code
└──────┬──────┘
│
▼
┌─────────────┐
│Tests Unitaires│ ← Rapide, bloque si échec
└──────┬──────┘
│
▼
┌─────────────┐
│ Build │
└──────┬──────┘
│
▼
┌─────────────┐
│Tests Intég. │ ← Plus long, bloque si échec
└──────┬──────┘
│
▼
┌─────────────┐
│ Tests E2E │ ← Avant déploiement staging
└──────┬──────┘
│
▼
┌─────────────┐
│ Déploiement│
└─────────────┘
Bonnes Pratiques
Règles d'Or
- Tests rapides d'abord - Unitaires avant intégration
- Paralléliser l'exécution - Réduire le temps total
- Tester les chemins critiques - Pas tout, le plus important
- Maintenir les tests - Supprimer les tests flaky
- Mesurer la couverture - Objectif réaliste, pas 100%
- Automatiser tout - Pas de tests manuels répétitifs
Éviter les Pièges
ANTI-PATTERNS DE TEST
═════════════════════
❌ Tests flaky (parfois passent, parfois échouent)
└── Solution : Isoler, supprimer ou stabiliser
❌ Tests trop couplés à l'implémentation
└── Solution : Tester le comportement, pas le code
❌ Pas de tests en CI
└── Solution : Tests obligatoires avant merge
❌ Tests lents qui bloquent tout
└── Solution : Paralléliser, optimiser, stratifier
❌ Ignorer les tests qui échouent
└── Solution : Corriger immédiatement ou supprimer