Preuve par le Comportement

Que fait Preuve par le Comportement ?

À utiliser lors de la révision d'une implémentation existante, d'un travail délégué ou de l'état de préparation à la livraison. Une commande verte, une revue statique ou un résumé d'agent ne constituent pas une preuve à moins qu'ils n'exercent le comportement revendiqué.

Quand l'utiliser

• Un agent déclare une tâche terminée.
• Les tests passent, mais leur force comportementale est inconnue.
• Une correction de bogue, une modification d'interface utilisateur, une intégration ou un changement opérationnel nécessite une validation.
• Une revue statique entre en conflit avec un comportement précédemment vérifié à l'exécution.

Ne pas utiliser ceci à la place de test-driven-development pour du nouveau code ; l'utiliser pour valider les preuves après ou parallèlement à l'implémentation.

Procédure

1. Nommer le comportement revendiqué.

   • Énoncer le résultat observable par l'utilisateur ou de l'extérieur qui est affirmé.
   • Achèvement : l'affirmation peut être testée sans se référer aux détails d'implémentation.

2. Choisir le joint d'essai réel le plus proche.

   • Privilégier une interaction avec un composant monté, une requête d'intégration, une invocation CLI, un appel API ou un flux de bout en bout plutôt qu'un test d'importation ou de snapshot uniquement.
   • Utiliser des charges utiles réalistes et des fixtures en forme de production.
   • Achèvement : la sonde atteint le chemin de code dont le comportement est revendiqué.

3. Prouver que la sonde a du mordant.

   • Pour un comportement modifié ou supprimé, observer d'abord un échec sans l'implémentation ou avec un no-op délibéré lorsque cela est sûr.
   • Un test qui reste vert lorsque l'unité modifiée est contournée est vide et ne doit pas être utilisé comme preuve.
   • Achèvement : la sonde peut distinguer le comportement fonctionnel du comportement cassé pertinent.

4. Exécuter et inspecter la preuve.

   • Exécuter la vérification ciblée, puis les vérifications plus larges applicables du projet.
   • Lire le test ou le harnais plutôt que de se fier à un résumé de son auteur.
   • Achèvement : la sortie et l'implémentation soutiennent toutes deux l'affirmation exacte.

5. Gérer les preuves contradictoires.

   • Traiter le comportement à l'exécution vérifié par l'utilisateur comme une preuve nécessitant une explication avant de le remplacer par une recommandation de revue statique.
   • Tracer le framework, le cache, l'infrastructure ou la sémantique d'exécution à l'origine de la contradiction apparente.
   • Achèvement : tout changement suit la preuve la plus forte disponible, et non la confiance du relecteur.

Pièges

• Ne pas vérifier le comportement de la console du navigateur avec Node. Le console.log de Node ne supporte pas %c — il traite les chaînes de style comme des arguments bruts et les ignore silencieusement, donc un harnais Node/Python imprime une grille propre et masque un rendu DevTools cassé. Pour vérifier la sortie de la console, piloter le vrai navigateur via CDP (Chrome headless --remote-debugging-port + un script WebSocket capturant Runtime.consoleAPICalled), ou obtenir des preuves visibles par l'utilisateur depuis la console réelle. Un harnais qui s'exécute sur un moteur de console différent n'est pas une preuve.
• Un console.log avec un très grand nombre de segments %c fait déborder DevTools. Le formateur de console consomme les arguments un spécificateur à la fois ; lorsqu'un seul appel a trop de segments stylisés (par exemple ~193), les chaînes de style de fin ne sont pas consommées comme des styles — elles s'impriment littéralement comme du texte non formaté (le classique dump de color:#...;font-family...). Remède selon la documentation Chrome : un console.log par ligne/row, chacun avec un nombre limité de runs %c. C'est pourquoi l'art ASCII par caractère sous forme d'un seul géant console.log('%c%s%c%s...') laisse fuir les styles.
• « Ne lève pas d'erreur au rendu », les fixtures de type uniquement, les mocks qui remplacent l'unité sous test et les tests .todo() ne prouvent pas le comportement.
• Ne jamais modifier le comportement de production uniquement pour satisfaire un échafaudage de test superficiel.
• Ne pas déclarer la tâche terminée lorsqu'une dépendance externe, une interaction UI ou un chemin de déploiement n'a pas été exercé ; signaler la limite non vérifiée.

Vérification

Un rapport d'achèvement doit inclure : le comportement prouvé, la commande ou l'action exacte utilisée, le résultat observé et toute limite qui reste non vérifiée.