MSW (Mock Service Worker) : intercepter et mocker vos APIs pour des tests fiables en 2026

Tester une application qui consomme des APIs sans tomber dans l'enfer des mocks fragiles ou des serveurs de test instables est un défi quotidien. MSW (Mock Service Worker) résout ce problème en interceptant les requêtes réseau au niveau du navigateur ou de Node.js, sans toucher à votre code applicatif. En 2026, cette bibliothèque est devenue le standard de fait pour mocker les APIs REST et GraphQL dans les projets React, Vue, Angular et Next.js.

Pourquoi MSW change la donne face aux mocks classiques

Les approches traditionnelles de mocking — stubber fetch, remplacer axios par un faux client, ou injecter des services factices — couplent fortement les tests à l'implémentation. Le moindre changement de bibliothèque HTTP casse tout, et les comportements mockés divergent souvent du vrai réseau (statuts, headers, délais). MSW intercepte les requêtes au niveau du Service Worker dans le navigateur et au niveau du module http dans Node.js, ce qui signifie que votre code applicatif fait de vraies requêtes fetch ou XHR — elles n'atteignent simplement jamais le réseau. Vous testez ainsi le chemin réel, avec les vrais headers, codes statut et payloads JSON, sans jamais modifier la configuration de votre client HTTP.

Une API de handlers expressive pour REST et GraphQL

MSW propose une API déclarative basée sur des handlers qui décrivent comment répondre aux requêtes. Pour une API REST, on écrit http.get('/api/users/:id', ({ params }) => HttpResponse.json(...)) et pour GraphQL graphql.query('GetUser', () => ...). Les handlers supportent l'extraction des paramètres d'URL, du body, des query strings et des headers, et permettent de simuler n'importe quel statut HTTP, du 200 au 503, avec des délais arbitraires. La version 2.x apportée en 2024 utilise désormais l'API Response standard du Web et supprime les dépendances Node spécifiques, ce qui permet à MSW de fonctionner identiquement dans Vitest, Jest, Playwright, Cypress et même dans le navigateur en mode développement.

Un seul jeu de mocks pour les tests, le dev et Storybook

L'argument décisif de MSW est la réutilisation. Le même fichier de handlers alimente vos tests unitaires Vitest, vos tests E2E Playwright, votre serveur de développement local quand le backend n'est pas prêt, et même vos stories Storybook pour documenter des états avec données. Cette unification supprime la dérive entre les fixtures de test et les données vues en développement, qui finit toujours par produire des bugs visibles uniquement en production. En activant MSW dans votre main.tsx ou main.ts derrière une variable d'environnement, vous offrez à toute l'équipe un environnement front-end autonome capable de fonctionner sans backend, idéal pour le travail en parallèle entre équipes ou la démo de fonctionnalités en cours.

Bonnes pratiques pour des tests stables et lisibles

Pour tirer le meilleur de MSW, organisez vos handlers par domaine fonctionnel — handlers/users.ts, handlers/orders.ts — plutôt qu'en un seul fichier monolithique. Utilisez server.use() dans les tests pour surcharger ponctuellement un handler, par exemple pour simuler une erreur 500 sur une route spécifique, et appelez server.resetHandlers() entre chaque test pour garantir l'isolation. Évitez de mocker tout votre backend : concentrez-vous sur les routes consommées par les composants testés, et laissez les autres requêtes passer en mode onUnhandledRequest: 'error' pour détecter immédiatement les appels inattendus. Enfin, combinez MSW avec Faker.js ou des factories typées pour générer des fixtures réalistes sans dupliquer manuellement les structures de données.