Qu'est-ce que le mocking d'API ? Outils, cas d'usage, exemples

Qu'est-ce que le mocking d'API ?

Le mocking d'API consiste à remplacer une API réelle par une simulation qui renvoie des réponses prédéfinies. Le client appelle les mêmes URL et reçoit le même format de réponse, mais rien n'atteint le vrai backend : pas de base de données, pas d'effets de bord, pas de facture d'un tiers. Comme vous maîtrisez les réponses, les tests deviennent déterministes et vous pouvez déclencher des cas difficiles à obtenir à la demande, comme une erreur 500 ou une réponse lente.

On utilise les mocks pour développer un frontend avant que le backend n'existe, pour que les tests automatisés ne dépendent pas de services parfois indisponibles et pour vérifier qu'un client gère bien les réponses documentées. Un mock est un outil de développement et de test, pas un substitut au test de l'API réelle. Voir aussi les tests d'API.

Comment fonctionne le mocking d'API

Un serveur mock (ou un intercepteur dans le processus de test) reçoit une requête, la reconnaît par méthode, chemin, en-têtes ou corps, et répond avec une réponse fixe ou calculée. On dirige le client vers le mock en changeant l'URL de base, généralement via une variable d'environnement ; un intercepteur, lui, capte les appels sortants sans toucher au code.

// Dev : API_BASE=http://localhost:8000 (mock)
// Prod : API_BASE=https://api.example.com (réel)
const API_BASE = process.env.API_BASE || 'https://api.example.com';
fetch(`${API_BASE}/users/42`);

Quand utiliser le mocking d'API

• Travail frontend avant que le backend soit prêt. On développe contre le JSON convenu, puis on change l'URL de base.
• Tests unitaires et d'intégration. Pas de réseau, pas de tiers peu fiable.
• Cas d'erreur. Renvoyer un 429, un 500 ou un timeout à volonté.
• APIs payantes ou limitées. Ne pas payer ni être bridé à chaque exécution des tests.
• Démos et travail hors ligne. Pas de données de production, pas de connexion nécessaire.

Types de mocks d'API

• Statique : toujours la même réponse.
• Dynamique : la réponse dépend du chemin, de la query string ou du corps.
• Enregistré : des réponses réelles capturées une fois, puis rejouées.
• Piloté par la spécification : généré à partir d'un fichier OpenAPI, le mock suit donc le schéma documenté (voir Swagger).
• Avec état : un POST crée quelque chose qu'un GET ultérieur renvoie. Utile pour les parcours de bout en bout, mais coûteux à maintenir.

Outils de mocking d'API courants

Exemple avec MSW (syntaxe v2) :

import { setupServer } from 'msw/node';
import { http, HttpResponse } from 'msw';

const server = setupServer(
  http.get('https://api.example.com/users/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Alice' });
  })
);
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Exemple avec nock :

const nock = require('nock');
nock('https://api.example.com')
  .get('/users/42')
  .reply(200, { id: 42, name: 'Alice' });

Mock, stub, fake et spy

• Stub : renvoie une réponse fixe.
• Mock : un stub qui vérifie en plus qu'il a été appelé comme prévu.
• Fake : une implémentation fonctionnelle mais simplifiée, comme une base de données en mémoire.
• Spy : enveloppe l'appel réel et enregistre ce qui a été envoyé.

Dans le langage courant, « mocking » recouvre les quatre. Les distinctions strictes ne comptent que dans les frameworks de tests unitaires.

Erreurs fréquentes

• Le mock dérive de l'API réelle. Le fournisseur change un champ, pas le mock : les tests restent verts et la production casse. Générez les mocks depuis la spécification ou utilisez le contract testing, qui vérifie les deux côtés contre le même contrat.
• Ne tester que contre des mocks. Gardez quelques tests d'intégration contre une API de préproduction ou réelle.
• Des mocks trop permissifs. L'API réelle valide les entrées et refuse ce que le mock accepte.
• Seulement le cas nominal. Ajoutez erreurs, résultats vides, réponses lentes et corps mal formés. Plus de détails dans les erreurs courantes de mocking en test d'API (en anglais).
• Un mock qui devient un second backend. S'il lui faut sa propre logique métier, utilisez plutôt un environnement de test.

Mocks, tests de charge et supervision

Un test de charge contre un mock mesure le mock, pas votre service : ne l'utilisez pas pour prouver que votre API tient la charge. Les mocks aident en revanche dans un test de charge quand un tiers lent ou limité se trouve derrière votre service : simulez cette dépendance pour que le résultat reflète votre propre code. Le vrai test de capacité se fait contre l'API réelle dans un environnement de préproduction, par exemple avec les tests de charge LoadFocus (scripts JMeter et k6).

Un mock ne vous prévient pas quand l'API réelle change après la mise en production. Les vérifications planifiées sur le endpoint réel le font : la supervision d'API LoadFocus appelle vos endpoints de façon planifiée (toutes les 5 minutes avec l'offre gratuite), contrôle le code de statut, le temps de réponse et le corps, et vous alerte en cas d'échec. À lire aussi : supervision d'API, endpoint d'API, tests de non-régression.

Questions fréquentes sur le mocking d'API

Quelle différence entre un mock et une API de préproduction ?

Un mock est local, rapide et entièrement sous votre contrôle. Une API de préproduction est un déploiement réel du service sans données de production. Utilisez les mocks pour les tests unitaires et le développement, la préproduction pour les tests d'intégration et de bout en bout.

Faut-il simuler toutes les APIs externes dans les tests ?

Dans les tests unitaires, oui, pour tester votre code isolément. Dans les tests d'intégration, gardez au moins quelques appels vers un service réel ou de préproduction pour détecter ce qu'un mock ne montre pas.

Comment simuler des réponses dynamiques ?

La plupart des outils calculent la réponse à partir de la requête : WireMock propose des modèles de réponse, Mockoon gère des données dynamiques et les handlers MSW sont de simples fonctions JavaScript.

Peut-on simuler GraphQL ou gRPC ?

GraphQL, oui : MSW le prend en charge. Pour gRPC, il faut un outil de mock dédié, car un mock HTTP classique ne parle pas ce protocole.

Comment garder un mock synchronisé avec l'API réelle ?

Générez-le depuis la spécification OpenAPI quand c'est possible et ajoutez des tests de contrat ou une vérification planifiée sur le endpoint réel, pour qu'un changement côté fournisseur fasse échouer un test plutôt que la production.