Vérification de test économique en coût
Réduire le travail redondant et la sortie sans affaiblir les vérifications nécessaires. Choisir un meilleur ordre peut économiser du temps d'exécution ; des rapports concis économisent du contexte, mais ne rendent pas un test déjà en cours plus rapide. Ne prétendez pas à des économies sans mesures.
Planifier et exécuter les vérifications
- Identifiez les composants affectés, les risques, les exigences du projet et les vérifications appropriées avant d'exécuter des suites coûteuses. Suivez les exigences explicites de l'utilisateur et du projet, y compris les vérifications obligatoires.
- Terminez d'abord la modification principale et la couverture de régression ciblée significative. Diagnostiquez et corrigez les échecs de construction ou de comportement avec la vérification la plus étroite pertinente. Stabilisez ensuite les scénarios d'intégration ou de bout en bout affectés. Pour les scénarios partagés nouveaux ou modifiés, comparez les attentes avec une référence disponible ; vérifiez et documentez séparément les différences intentionnelles.
- Une fois que la modification et les vérifications ciblées sont stables, exécutez la suite finale requise, les vérifications statiques et les constructions selon le cas. Ne réutilisez un résultat réussi que tant que le code, les dépendances, la configuration, l'environnement et le scénario pertinents restent inchangés.
- Après une correction, relancez les vérifications affectées. Répétez la suite large lorsque l'impact est large, les dépendances changent, les exigences le demandent ou que l'exactitude reste incertaine. Ne répétez pas automatiquement une suite complète pour chaque échec local.
- Pour un échec intermittent, conservez le premier échec et relancez le test seul ; si nécessaire, exécutez sa suite en série pour enquêter sur les interférences. Signalez l'instabilité non résolue plutôt que de considérer un passage ultérieur comme une preuve que l'échec est corrigé.
- Pour les modifications de documentation uniquement, vérifiez le diff, les liens pertinents et la syntaxe ; n'exécutez les tests d'application que lorsque cela est requis ou pertinent. Isolez les mesures de performance des constructions et tests simultanés qui pourraient fausser les résultats.
- Interrogez les tâches longues à intervalles raisonnables plutôt que de lire à plusieurs reprises une sortie inchangée. Évitez de redémarrer un travail simplement pour vérifier la progression.
Garder la sortie utile et bornée
Préférez un exécuteur de projet ou un outil de rapport existant. Capturez la sortie standard et les erreurs standard complètes dans un journal unique et non écrasant lorsque cela est approprié, et renvoyez un résumé concis : résultat de la commande et code de sortie, durée, nombres de tests reconnaissables, y compris les tests ignorés ou sauté, et emplacement du journal. En cas d'échec, incluez les noms des cas échoués et un extrait diagnostique borné ; inspectez la partie pertinente du journal complet si le résumé est insuffisant. Ne déduisez jamais le succès global des comptes partiels de suite : utilisez le code de sortie réel de la commande, et indiquez quand un résumé ne peut pas être analysé. Préservez les erreurs de lancement, l'annulation et le comportement des signaux. N'empilez pas de wrappers redondants autour d'un exécuteur existant.
Vérifier l'infrastructure de test
Lors de la création ou de la modification substantielle d'un exécuteur de test, d'un wrapper ou d'un outil de rapport, testez la fiabilité de ses résultats. Choisissez des cas en fonction de ce que l'outil fait réellement et du risque de cacher ou de déformer un échec. Les cas utiles incluent :
- Un échec ultérieur après une suite réussie reste un échec, avec le code de sortie correct.
- La sortie complète est conservée même lorsque les diagnostics affichés sont bornés.
- Les sauts, les erreurs de lancement, les résumés non reconnus et les interruptions sont signalés ou propagés correctement, le cas échéant.
Exercez le comportement observable, y compris la frontière avec le processus de test sous-jacent. Adaptez l'analyse à l'infrastructure réelle et évitez les tests qui ne font que dupliquer l'implémentation. Il s'agit d'une vérification de l'infrastructure, non d'une exigence d'écrire des tests pour chaque test individuel. Ne réécrivez pas et ne retestez pas un outil fiable existant uniquement parce que cette compétence est utilisée.
Écrire des tests de diagnostic
Gardez les tests réussis silencieux à moins que la sortie de progression ne soit utile. Les échecs doivent identifier le cas, le comportement attendu et réel, les paramètres pertinents et toute graine aléatoire. Décrivez les charges utiles volumineuses avec des longueurs, l'emplacement de la divergence, de courts extraits ou des hachages au lieu de tout vider. Activez les détails par itération ou les traces complètes pour le diagnostic si nécessaire. Marquez les sauts explicitement avec des raisons, et ne convertissez jamais un échec en sortie réussie. Améliorez les tests existants bruyants lorsque vous travaillez dessus plutôt que de réécrire une suite saine uniquement pour le formatage.