Mocking vs Stubbing

Testing 🟡 Mid

Définition

Le stub fournit des réponses prédéfinies sans vérifier les appels. Le mock vérifié en plus que les interactions attendues ont bien eu lieu (nombre d'appels, arguments).

Analogie

Le stub est un distributeur automatique (il donne la réponse), le mock est un serveur de restaurant qui note ce que vous commandez ET vérifie que vous avez bien commande.

Exemple de code

// Stub : on ne verifie pas l'appel
vi.spyOn(api, 'fetch').mockReturnValue({ data: 'ok' });

// Mock : on verifie l'interaction
const sendEmail = vi.fn();
await registerUser('[email protected]');
expect(sendEmail).toHaveBeenCalledWith('[email protected]');
expect(sendEmail).toHaveBeenCalledTimes(1);

Cas d'usage

Utiliser des stubs pour les queries (get data) et des mocks pour les commands (send email, write DB).

Anti-pattern

Sur-mocker en vérifiant chaque appel interne, couplant les tests a l'implémentation plutôt qu'au comportement.
#testing#interview#fondamental

En entretien

  1. Quelle différence fais-tu entre un stub et un mock ?

    Le stub se contente de renvoyer une réponse prédéfinie sans vérifier comment il a été appelé. Le mock vérifie en plus les interactions attendues, comme le nombre d'appels ou les arguments passés.

  2. Dans quel cas utiliserais-tu plutôt un stub, et dans quel cas un mock ?

    J'utilise un stub pour les queries, quand je veux juste simuler une donnée lue comme un fetch. J'utilise un mock pour les commands, comme l'envoi d'un email, où je dois vérifier que l'action a bien été déclenchée.

  3. Pourquoi dit-on que sur-mocker rend les tests fragiles ?

    Vérifier chaque appel interne couple le test à l'implémentation plutôt qu'au comportement observable. Le moindre refactoring interne fait alors échouer des tests qui ne devraient pas être concernés.

Fiche mise à jour le 2026-09-27

← → au clavier pour passer d'une fiche à l'autre