Aller au contenu principal

Stratégie de test et confiance dans le système

Les tests répondent à des questions différentes. Classez-les selon la frontière exercée et les preuves fournies, pas seulement leur nom de fichier.

CoucheQuestion principaleCompromis typique
UnitaireLe comportement métier ciblé tient-il ?rapide, réalisme limité
IntégrationLes composants réels partagent-ils le contrat ?plus de préparation et de modes d'échec
Système / bout en boutUn parcours utilisateur représentatif fonctionne-t-il ?lent, large, diagnostic difficile
ContratDes versions indépendantes producteur/consommateur interopèrent-elles ?politique de version commune requise
Performance / chargeLe comportement tient-il sous une charge définie ?sensible à l'environnement
SécuritéDes abus connus peuvent-ils franchir une frontière ?modèles de menace évolutifs requis

Les tests en boîte noire vérifient le comportement par les entrées et sorties publiques. Ceux en boîte blanche exploitent la connaissance de l'implémentation pour viser branches ou états. Une suite saine emploie les deux sans faire de chaque refactorisation une réécriture.

Choisir les cas selon le risque

Testez comportement ordinaire, limites, entrées invalides, échecs partiels, nouvelles tentatives, concurrence et récupération là où ces risques existent réellement. Un test de régression préserve un comportement précédemment manqué. Un test de fumée vérifie un petit chemin critique après construction ou déploiement ; il ne remplace pas la suite complète.

Les tests par propriétés et le fuzzing explorent de vastes espaces lorsque les invariants sont plus clairs que des exemples choisis. Ils complètent les exemples lisibles des scénarios métier importants sans les remplacer.

La CI comme contrôle de reproductibilité

L'intégration continue doit partir d'un environnement déclaré, installer des dépendances verrouillées ou contraintes et exécuter des contrôles déterministes obligatoires. Placez le signal rapide tôt et isolez les suites coûteuses ou propres à un environnement avec une responsabilité claire.

Un test obligatoire en échec doit bloquer le changement ou suivre une procédure d'exception explicite. Ne normalisez pas « relancer jusqu'au vert ». Un test instable révèle du non-déterminisme dans le test, le produit ou l'environnement ; consignez-le, attribuez-le et corrigez-le ou mettez-le en quarantaine avec échéance et visibilité préservée.

Des preuves, pas un score

La couverture des lignes et branches révèle le code non exécuté, mais ne mesure ni qualité des assertions, ni réalisme des données, ni exigences manquantes. Les tests par mutation détectent des contrôles qui exécutent le code sans remarquer les changements, au prix d'un calcul supplémentaire.

Observabilité en production, déploiement progressif, retour arrière et revue d'incident couvrent des conditions qu'un environnement de test ne reproduit pas entièrement. La fiabilité vient de tout le système de retour, pas d'une pyramide ou d'un pourcentage.

Sources

Explorer les liensOuvrir le réseau