0%
Doublures et réseau

Doublures et réseau

Une doublure trop complaisante transforme votre suite de tests en machine à produire de la confiance injustifiée

10-15 min

Doublures et réseau

Votre page de facturation est couverte par vingt tests verts. En production, elle affiche NaN € depuis trois jours. Vous ouvrez les tests : ils simulent le client HTTP avec vi.mock, et la doublure renvoie { montant: 1290 }. Le vrai service, lui, renvoie { montant: "1290.00", devise: "EUR" } depuis une migration back-end du mois dernier. Vos tests n'ont jamais vérifié le contrat réel : ils ont vérifié que votre code fonctionne avec les données que vous avez inventées pour lui.

C'est le risque central de toute doublure, et il est structurel : vous remplacez une dépendance par une version simplifiée, donc vous supprimez de la surface de test exactement la partie que vous ne contrôlez pas. La question n'est jamais « faut-il simuler » mais « à quel niveau couper », et la réponse est presque toujours : le plus bas possible. Intercepter au niveau HTTP laisse tourner votre client, votre sérialisation, votre gestion d'erreurs et votre analyse de réponse — c'est-à-dire tout le code où les bugs se logent réellement. Simuler le module qui appelle l'API supprime tout cela d'un coup.

Commentaires

Les commentaires sont alimentés par GitHub Discussions

Connectez-vous avec GitHub pour participer à la discussion

Lien copié !