21. Le portefeuille de tests : combiner précision et réalisme
Pourquoi ce chapitre existe
La « pyramide des tests » a simplifié une idée juste — il vaut mieux beaucoup de retours rapides et ciblés — jusqu'à devenir parfois une règle de comptage. Les systèmes actuels ne se résument pas à une interface et une base : ils combinent événements, services tiers, configurations, données historiques et expériences utilisateur. Le bon portefeuille ne suit pas une forme imposée ; il attribue à chaque niveau une question qu'il est particulièrement apte à résoudre.
Les idées essentielles
- Les niveaux de test sont complémentaires : local, composant, contrat, intégration, parcours et production contrôlée.
- Le meilleur niveau est le plus petit environnement qui peut produire une preuve crédible pour le risque étudié.
- Un test de bout en bout est précieux pour un parcours critique, mais coûteux et insuffisant comme stratégie unique.
- Les tests doivent être organisés par propriétés et modes de défaillance, non par préférence d'outil.
Choisir le niveau par la question
Un calcul fiscal demande des cas de décision rapides et nombreux. Une modification d'événement demande une preuve de contrat. Un enchaînement de paiement demande quelques parcours intégrés représentatifs. La bonne question précède le choix du framework.
| Niveau | Question bien traitée | Coût et limite |
|---|---|---|
| Unité ou domaine | La décision est-elle correcte pour ces entrées ? | Ne valide pas l'assemblage réel |
| Composant | Le module réagit-il correctement avec ses adaptateurs ? | Peut diverger de l'environnement partagé |
| Contrat | Les parties tiennent-elles leur engagement ? | Ne prouve pas le flux complet |
| Intégration | Stockage, transport et configuration fonctionnent-ils ensemble ? | Plus lent, diagnostic plus large |
| Parcours | L'utilisateur réussit-il une capacité critique ? | Fragile si trop étendu ou trop nombreux |
| Production contrôlée | Le système tient-il sous le vrai trafic et les vraies données ? | Exposition à limiter et observer |
Maintenir les données de test comme un actif
Les données irréalistes cachent les problèmes de volume, de permissions, de dates et d'historique. Les données de production copiées sans précaution créent, elles, des risques de confidentialité et de conformité. Construire des jeux synthétiques représentatifs, des générateurs et des échantillons anonymisés est un investissement qui améliore à la fois la qualité et la vitesse de diagnostic.
Anti-patterns
Tout tester par l'interface
Une suite qui ne connaît que le navigateur ou l'API publique détecte des défauts réels, mais devient lente et difficile à diagnostiquer. Elle incite à réduire les scénarios plutôt qu'à augmenter la précision des preuves.
Tout tester avec des doubles
Une suite entièrement isolée peut être rapide et rassurante tout en ignorant les contrats réellement exposés. Les tests locaux doivent être complétés par des preuves au niveau où les dépendances se rencontrent.
Faire dépendre chaque test d'un environnement mutable
Un environnement partagé sans remise à zéro introduit ordre, concurrence et données résiduelles. Les tests cessent alors d'être des expériences reproductibles. Isoler, provisionner à la demande ou contrôler les données rétablit la confiance.
Bonnes pratiques
Garder peu de parcours, mais les choisir explicitement
Un parcours de bout en bout justifie son coût lorsqu'il couvre une capacité critique, une intégration difficile à simuler ou un risque de configuration. Il doit être observable, stable et entretenu comme un produit, pas accumulé au fil des bugs.
Utiliser l'échec pour déplacer une preuve
Lorsqu'un incident est découvert tard, demander quel niveau aurait pu le révéler plus tôt et à moindre coût. La réponse n'est pas toujours « ajouter un E2E » : elle peut être une contrainte de données, un contrat, une métrique ou un test de composant.
Checklist — Le portefeuille est-il équilibré ?
- Quels comportements critiques dépendent d'une seule forme de preuve ?
- Quel test est excessivement lent ou difficile à diagnostiquer pour la question qu'il pose ?
- Les contrats externes et les configurations significatives sont-ils couverts au bon niveau ?
- Les données de test représentent-elles les états, volumes et permissions qui comptent ?
- Les parcours E2E ont-ils une raison explicite d'exister ?
- Quel incident récent révèle un angle mort du portefeuille ?
À retenir
Il n'existe pas de ratio universel de tests. Un portefeuille sain combine les preuves les plus rapides possibles avec celles qui confrontent réellement les contrats, les données et les parcours dont dépend la confiance des utilisateurs.