Alternative à Mock Service Worker (MSW) : quand opter pour une plateforme de mocking d'API complète

Si vous écrivez des tests frontend, vous avez probablement utilisé Mock Service Worker (MSW). C’est un excellent outil pour intercepter les requêtes dans le navigateur et Node, surtout dans les tests unitaires et de composants. Ce guide montre comment l’utiliser efficacement, où ses limites apparaissent à l’échelle, et quand une plateforme de simulation d’API hébergée devient plus adaptée.

Essayez Apidog aujourd’hui

Qu’est-ce que Mock Service Worker ?

Mock Service Worker est une bibliothèque JavaScript qui intercepte les requêtes réseau à la source.

• Dans le navigateur, MSW enregistre un Service Worker qui intercepte fetch et XMLHttpRequest.
• Dans Node, MSW intercepte la couche de requête pour exécuter les mêmes gestionnaires dans Jest, Vitest ou d’autres environnements de test.

Vous définissez des handlers qui correspondent à une méthode HTTP et à un chemin, puis vous retournez la réponse attendue.

Exemple minimal :

import { http, HttpResponse } from 'msw'

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({
      id: params.id,
      name: 'Ada Lovelace',
    })
  }),
]

Votre application continue d’appeler ses vraies URLs applicatives. MSW se place entre le code et le réseau, sans vous obliger à mocker directement fetch ni à modifier votre client HTTP.

Vous pouvez consulter le code source de MSW sur GitHub pour comprendre le fonctionnement de la couche d’interception.

Utiliser MSW dans un projet frontend

MSW est particulièrement utile quand la maquette et le consommateur vivent dans le même dépôt.

1. Définir les handlers

Créez un fichier dédié, par exemple src/mocks/handlers.js :

import { http, HttpResponse } from 'msw'

export const handlers = [
  http.get('/api/users/:id', ({ params }) => {
    return HttpResponse.json({
      id: params.id,
      name: 'Ada Lovelace',
      email: '[e-mail]',
    })
  }),

  http.get('/api/projects', () => {
    return HttpResponse.json([
      { id: 'p1', name: 'Website redesign' },
      { id: 'p2', name: 'Mobile app' },
    ])
  }),
]

2. Configurer MSW pour les tests Node

Dans un environnement Jest ou Vitest, créez un serveur MSW :

// src/mocks/server.js
import { setupServer } from 'msw/node'
import { handlers } from './handlers'

export const server = setupServer(...handlers)

Puis démarrez-le dans votre configuration de test :

// src/setupTests.js
import { server } from './mocks/server'

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

3. Surcharger une réponse dans un test

Vous pouvez modifier un comportement uniquement pour un test :

import { http, HttpResponse } from 'msw'
import { server } from '../mocks/server'

test('affiche une erreur si l’API échoue', async () => {
  server.use(
    http.get('/api/users/:id', () => {
      return new HttpResponse(null, { status: 500 })
    })
  )

  // render(...)
  // assert(...)
})

Cette approche garde les tests déterministes et évite de dépendre d’un serveur réel.

Les points forts de MSW

MSW est le bon choix lorsque les mocks servent principalement aux tests JavaScript.

Cas d’usage typiques :

• Tests de composants et unitaires : le composant déclenche de vraies requêtes, MSW retourne les réponses attendues.
• Développement frontend local : vous pouvez construire l’interface avant que le backend soit disponible.
• États API contrôlés : succès, chargement, erreurs, réponses vides, permissions, pagination.
• CI déterministe : les tests ne dépendent pas du réseau ni de données de staging partagées.
• Même dépôt, même équipe : les handlers sont versionnés avec le code frontend.

Si vous hésitez entre MSW et un mock direct du client HTTP, comparez cette approche avec un mock Jest d’un appel API.

En pratique, MSW fonctionne très bien quand :

frontend code + tests + mocks = même dépôt

Dans ce contexte, il est simple, gratuit, open source et très efficace.

Où MSW commence à montrer ses limites

MSW est conçu comme une bibliothèque de mock côté code. Cette force devient une limite quand les mocks doivent être partagés hors du dépôt frontend.

Consommateurs non JavaScript

Les handlers MSW sont écrits en JavaScript.

Si une équipe mobile utilise Swift ou Kotlin, ou si des tests backend sont écrits en Go ou Python, ces consommateurs ne peuvent pas importer directement vos handlers MSW.

Dans ce cas, un serveur de maquette exposé via HTTP est plus adapté :

https://mock.example.com/api/users/123

Tout client peut appeler cette URL, quel que soit le langage.

Maquettes partagées et toujours actives

MSW s’exécute dans un processus local :

• un navigateur ;
• un test runner ;
• une session de développement.

Il ne fournit pas une URL stable que toute l’équipe peut utiliser en parallèle.

Si un QA, un designer, une équipe mobile ou un partenaire externe doit tester contre la même API simulée, il faut une maquette hébergée avec une URL partagée.

Workflows basés sur OpenAPI

Si votre équipe travaille en API-first, vous commencez souvent par une spécification OpenAPI.

Dans ce cas, vous voulez idéalement :

1. définir le contrat ;
2. générer la documentation ;
3. générer les mocks ;
4. tester contre le même schéma.

MSW ne génère pas automatiquement les handlers depuis OpenAPI. Vous les écrivez à la main.

Pour un workflow schema-first, une solution de simulation d’API peut générer les réponses directement depuis la spécification.

Données réalistes à grande échelle

Avec MSW, vous contrôlez entièrement la réponse :

return HttpResponse.json({
  id: 'u1',
  email: '[e-mail]',
  createdAt: '2026-06-01T10:00:00Z',
})

C’est parfait pour des tests précis.

Mais si vous devez maintenir de nombreux endpoints avec beaucoup de champs, écrire manuellement toutes les réponses devient coûteux. Les plateformes qui génèrent des données réalistes à partir des noms de champs réduisent ce travail répétitif.

MSW vs plateforme complète de simulation d’API

Capacité	Mock Service Worker	Plateforme API hébergée, ex. Apidog
Tests unitaires/composants JS	Oui, natif	Non, ce n’est pas une bibliothèque de test JS
Fonctionne via HTTP pour tout langage	Non, JS uniquement	Oui
URL partagée pour l’équipe	Non	Oui
Génération depuis OpenAPI	Manuelle	Automatique depuis le schéma
Données dynamiques réalistes	À coder	Intégré
Versionné avec les tests	Oui	Stocké dans un projet partagé
Coût	Gratuit, open source	Niveau gratuit + plans payants

Résumé pratique :

• utilisez MSW pour les tests frontend et le développement local ;
• utilisez une plateforme comme Apidog quand la maquette doit être partagée, stable, accessible par HTTP ou générée depuis une spécification.

Apidog comme complément, pas comme remplacement

Apidog ne remplace pas MSW dans Jest ou Vitest.

Ce n’est pas une bibliothèque JavaScript à importer dans vos tests. C’est une couche complémentaire pour les mocks partagés au niveau équipe.

Un workflow courant :

1. Concevoir ou importer une API dans Apidog.
2. Générer un serveur de mock depuis le schéma.
3. Partager l’URL de mock avec le frontend, le mobile, la QA ou les partenaires.
4. Utiliser des réponses réalistes générées à partir des champs.
5. Ajouter des règles spécifiques pour les erreurs ou cas limites.

Exemple de répartition :

MSW
├─ tests unitaires
├─ tests de composants
└─ développement frontend local

Apidog
├─ mock server partagé
├─ consommateurs non-JS
├─ démonstrations
├─ QA
└─ workflow OpenAPI-first

Comme la maquette hébergée vient du même schéma que la conception API, elle reste alignée avec le contrat. C’est plus difficile à garantir avec des handlers écrits manuellement.

Pour comparer plusieurs options, consultez ce récapitulatif des meilleurs outils de simulation d’API.

Une stratégie simple :

• gardez MSW dans le dépôt frontend ;
• ajoutez une maquette hébergée pour les tests inter-équipes ;
• utilisez OpenAPI comme source de vérité quand le contrat API doit être partagé.

Vous pouvez télécharger Apidog pour tester cette approche à côté de votre configuration MSW existante.

Autres alternatives à MSW

MSW n’est pas la seule option. Le bon choix dépend de votre stack et de votre workflow.

Mockoon

Mockoon est une application de bureau pour lancer rapidement des serveurs de mock locaux avec une interface graphique.

Utile si vous voulez éviter d’écrire du code pour chaque endpoint.

WireMock

WireMock est un serveur de mock basé sur Java.

Il convient bien aux équipes JVM, aux tests de contrat et aux environnements backend.

Prism

Prism, de Stoplight, génère une maquette depuis un fichier OpenAPI via la ligne de commande.

C’est une bonne option si vous voulez rester proche du contrat OpenAPI sans passer par une plateforme complète.

json-server

json-server transforme un fichier JSON en API REST rapide.

Exemple :

{
  "users": [
    { "id": 1, "name": "Ada Lovelace" },
    { "id": 2, "name": "Grace Hopper" }
  ]
}

Puis :

npx json-server db.json

C’est pratique pour du prototypage rapide, mais moins adapté aux contrats API complexes.

Si votre besoin principal est de mocker une API côté React, voyez aussi cette approche de simulation d’API en React avec Axios.

Questions fréquentes

MSW est-il gratuit ?

Oui. Mock Service Worker est open source sous licence MIT et gratuit pour les projets personnels ou commerciaux.

Vous ne commencez à payer que si vous ajoutez une plateforme hébergée pour des mocks partagés. Des outils comme Apidog proposent aussi un niveau gratuit.

Apidog peut-il remplacer MSW dans mes tests unitaires ?

Non.

MSW intercepte les requêtes dans votre environnement de test JavaScript. Apidog est une plateforme hébergée, pas une bibliothèque importable dans Jest ou Vitest.

Utilisez :

• MSW pour les tests unitaires et de composants ;
• Apidog pour les mocks partagés, inter-équipes ou basés sur OpenAPI.

Pour les approches directement dans le code, consultez ce guide sur la manière de simuler des appels API.

MSW fonctionne-t-il dans Node ?

Oui.

MSW fonctionne dans deux environnements :

• navigateur : via Service Worker ;
• Node : via interception de la couche de requête.

Cela permet de réutiliser les mêmes handlers dans Jest, Vitest et le développement local.

Quand ajouter un serveur de mock hébergé ?

Ajoutez un serveur de mock hébergé lorsque la maquette doit sortir du dépôt frontend.

Signaux typiques :

• une équipe mobile doit consommer l’API simulée ;
• la QA a besoin d’une URL stable ;
• plusieurs développeurs doivent tester contre les mêmes réponses ;
• vous travaillez à partir d’une spécification OpenAPI ;
• vous voulez générer les mocks automatiquement depuis le contrat.

Conclusion

MSW est excellent pour intercepter les requêtes en JavaScript dans les tests frontend, les tests unitaires et le développement local. Il est simple, proche du code et parfaitement adapté aux équipes qui travaillent dans un même dépôt.

Mais MSW n’est pas conçu pour fournir une maquette hébergée, partagée et agnostique au langage. Dès que vos mocks doivent être utilisés par d’autres équipes, d’autres langages ou un workflow OpenAPI-first, ajoutez une plateforme dédiée.

Apidog couvre cette partie : serveur de mock hébergé, URL réelle, génération depuis OpenAPI et données réalistes prêtes à l’emploi.

Gardez MSW là où il est fort. Utilisez Apidog lorsque vos mocks doivent devenir une ressource partagée.