Quelle est la différence entre un mock, un stub et un fake, et quand utilisez-vous plutôt une vraie dépendance ?

Un stub renvoie des réponses préparées pour que le code testé puisse continuer. Un mock enregistre en plus les interactions pour que vous puissiez affirmer qu'elles ont eu lieu, en vérifiant le comportement plutôt que l'état. Un fake est une implémentation légère mais fonctionnelle, par exemple un dépôt en mémoire. Utilisez de vraies dépendances quand l'intégration elle-même est le risque, et des doublures quand la dépendance est lente, coûteuse ou difficile à forcer dans un état donné.

Un stub est passif, il se contente de renvoyer ce que vous lui avez dit de renvoyer pour que le code continue. Un mock est un stub qui se souvient en plus de ce qui lui est arrivé, pour que vous puissiez affirmer que le service de paiement a été appelé exactement une fois avec ces arguments. Un fake est une implémentation réelle mais simplifiée, comme une version en mémoire d'un dépôt, qui se comporte correctement mais n'est pas de qualité production. La distinction qui compte en pratique, c'est que les stubs et les fakes soutiennent la vérification d'état, on affirme sur le résultat, alors que les mocks soutiennent la vérification d'interaction, on affirme sur la conversation. Je penche pour la première, parce qu'affirmer sur les interactions couple le test aux détails d'implémentation, et un refactoring casse alors cent tests sans qu'un seul comportement ait changé. Là où j'utilise de vraies dépendances, c'est partout où l'intégration est le risque. Si la question est de savoir si notre requête fonctionne vraiment contre Postgres, une base mockée ne répond rien, donc je lance la vraie dans un conteneur. C'est désormais mon choix par défaut pour la couche d'intégration, puisque les conteneurs l'ont rendu bon marché. Je mocke les services tiers que je ne contrôle pas, puis j'adosse cela à des tests de contrat planifiés contre leur bac à sable.