Doublures et réseau
Une doublure trop complaisante transforme votre suite de tests en machine à produire de la confiance injustifiée
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