Si vous écrivez des tests frontend, vous avez probablement rencontré Mock Service Worker (MSW). C'est la bibliothèque de référence pour intercepter les requêtes dans le navigateur et Node, et pour les tests unitaires et de composants, elle est difficile à battre. Ce guide explique ce que MSW fait bien, où il atteint ses limites de mise à l'échelle, et quand une plateforme de simulation d'API hébergée est plus judicieuse.
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, elle enregistre un Service Worker qui intercepte les appels fetch et XMLHttpRequest sortants. Dans Node, elle modifie la couche de requête pour que les mêmes gestionnaires s'exécutent dans Jest ou Vitest. Vous écrivez des gestionnaires de requêtes qui correspondent à une méthode et un chemin, puis vous renvoyez la réponse que vous souhaitez.
La conception est astucieuse. Votre code d'application continue d'appeler les véritables API réseau. MSW se positionne au milieu et répond, de sorte que vous n'avez pas à simuler fetch ou à changer votre client HTTP. Les mêmes définitions de maquettes fonctionnent dans les tests et dans une version de développement en cours, c'est pourquoi tant d'équipes React et Vue l'utilisent. Vous pouvez explorer le code source de MSW sur GitHub pour voir comment fonctionne la couche d'interception.
Un gestionnaire typique ressemble à ceci :
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
}),
]
C'est tout l'intérêt. La maquette vit à côté de votre code, elle est versionnée avec vos tests, et elle s'exécute partout où votre JavaScript s'exécute.
Les points forts de MSW
MSW est parfaitement adapté lorsque la maquette et le consommateur résident dans la même base de code. Voici quelques cas où c'est véritablement l'outil idéal :
- Tests de composants et unitaires. Rendez un composant, laissez-le déclencher ses requêtes réelles et renvoyez des données préenregistrées. Pas besoin de doubler les tests. Si vous le comparez à l'espionnage direct du client, voyez en quoi cela diffère d'un mock Jest d'un appel API.
- Développement frontend local. Construisez l'interface utilisateur avant que le backend n'existe. Basculez les gestionnaires pour simuler le chargement, les erreurs ou les états vides à la demande.
- Intégration Continue déterministe. Les tests ne touchent pas un serveur réel, ils ne sont donc pas sensibles aux conditions réseau ou aux données de staging partagées.
- Une langue, une équipe. Lorsque les personnes qui écrivent la maquette sont celles qui la consomment, conserver les gestionnaires dans le dépôt est le chemin le plus simple.
Si cela décrit votre situation, vous n'avez probablement besoin de rien d'autre. MSW est gratuit, open source et conçu précisément pour cela.
Où MSW commence à montrer ses limites
Ce qui rend MSW excellent dans un seul dépôt, à savoir des maquettes qui vivent sous forme de code dans ce dépôt, est ce qui le limite une fois que davantage de personnes sont impliquées. Voici les situations où les équipes ont tendance à le dépasser.
Consommateurs non-JavaScript
Les gestionnaires MSW sont en JavaScript. Si votre équipe mobile écrit en Swift ou Kotlin, ou si vos tests d'intégration backend s'exécutent en Go ou Python, ils ne peuvent pas importer vos gestionnaires. Ils auraient besoin de leurs propres maquettes, qui s'éloigneraient des vôtres. Un serveur de maquette agnostique au langage qui communique en HTTP via une URL réelle fonctionne pour chaque client, quelle que soit la langue.
Maquettes partagées et toujours actives
MSW s'exécute à l'intérieur d'un processus. Il n'y a pas d'URL partagée qu'un ingénieur QA, un concepteur ou une équipe partenaire puisse atteindre depuis sa propre machine. Dès que vous souhaitez un point d'accès que plusieurs personnes utilisent simultanément, vous avez besoin d'un serveur de maquette hébergé avec une adresse stable, et non d'un Service Worker lié à un seul onglet de navigateur.
Workflows axés sur la conception et basés sur des schémas
Si vous concevez des API en OpenAPI avant d'écrire du code, vous souhaitez que les maquettes soient générées automatiquement à partir de la spécification, afin que la maquette ne contredise pas le contrat. MSW s'attend à ce que vous écriviez les gestionnaires à la main. La génération de maquettes directement à partir d'un schéma est un modèle différent. Vous pouvez en savoir plus sur cette approche dans ce guide sur la simulation d'API et les modèles qui l'entourent.
Données réalistes et dynamiques à grande échelle
MSW renvoie ce que votre gestionnaire code. Pour des données réalistes sur de nombreux champs, vous écrivez cette logique vous-même. Les plateformes qui intègrent la génération de style "faker" et l'inférence de noms de champs vous donnent des réponses réalistes sans avoir à coder chacune d'elles à la main.
MSW vs une plateforme complète de simulation d'API
Voici une comparaison honnête. Aucune colonne n'est "meilleure" dans l'absolu ; elles résolvent des problèmes différents.
| Capacité | Mock Service Worker | Plateforme API hébergée (ex. Apidog) |
|---|---|---|
| S'exécute dans les tests unitaires/composants JS | Oui, natif | Non, ce n'est pas une bibliothèque de tests JS |
| Agnostique au langage via HTTP | Non (JS seulement) | Oui, tout client |
| URL partagée pour toute l'équipe | Non | Oui, serveur de maquette hébergé |
| Générer des maquettes à partir d'OpenAPI | Manuel | Automatique à partir du schéma |
| Génération de données intelligentes/dynamiques | Codé à la main | Intégré |
| Vit dans votre dépôt avec les tests | Oui | Stocké dans un projet partagé |
| Coût | Gratuit, open source | Tier gratuit + plans payants |
En résumé : MSW est le bon choix pour les tests frontend et le développement local. Une plateforme comme Apidog est le bon choix lorsque la maquette doit être partagée, agnostique au langage ou basée sur une spécification.
Apidog comme complément, pas comme remplacement
Pour être clair, Apidog ne remplace pas MSW directement dans Jest ou Vitest. Ce n'est pas une bibliothèque JavaScript que vous importez dans un fichier de test. Considérez-le comme la couche supérieure de vos tests unitaires, l'endroit où les maquettes deviennent une ressource partagée, agnostique au langage, pour toute l'équipe.
Voici ce à quoi cela ressemble en pratique. Vous concevez ou importez une API dans Apidog, et celle-ci génère automatiquement un point d'accès de maquette à partir du schéma. La maquette obtient une URL réelle que vos coéquipiers frontend, mobile et QA peuvent tous appeler. Apidog remplit les réponses avec des données réalistes en les inférant des noms de champs, de sorte qu'un champ nommé email renvoie un e-mail et createdAt renvoie une date. Vous pouvez également écrire des règles personnalisées lorsque vous avez besoin d'une réponse 500 spécifique ou d'un cas limite particulier.
Étant donné que la maquette provient du même schéma que votre conception et vos tests, elle reste synchronisée avec le contrat. C'est la partie que les gestionnaires écrits à la main ne peuvent pas garantir. Si vous voulez voir comment la génération de schémas en maquettes se compare entre les outils, ce récapitulatif des meilleurs outils de simulation d'API met les options côte à côte.
Une répartition pratique que de nombreuses équipes adoptent :
- Gardez MSW pour les tests de composants et unitaires au sein du dépôt frontend.
- Utilisez une maquette hébergée pour l'intégration inter-équipes, les démonstrations et tout consommateur non-JS.
Vous ne choisissez pas l'un ou l'autre. Vous utilisez chacun là où il est pertinent. Téléchargez Apidog si vous souhaitez essayer le côté hébergé en parallèle de votre configuration MSW existante.
Autres alternatives à MSW à connaître
MSW n'est pas la seule bibliothèque de simulation, et une plateforme n'est pas votre seule option. Selon votre stack :
- Mockoon est une application de bureau pour lancer rapidement des serveurs de maquettes locaux, avec une interface graphique au lieu de code.
- WireMock est un serveur de maquette basé sur Java, solide pour les équipes JVM et les tests de contrat.
- Prism de Stoplight génère une maquette directement à partir d'un fichier OpenAPI via la ligne de commande.
- json-server transforme un fichier JSON en une API REST rapide pour le prototypage.
Chacun a ses compromis. WireMock et Prism sont orientés vers le backend et le travail contractuel ; Mockoon et json-server sont orientés vers une configuration locale rapide. Si votre problème est spécifiquement "MSW ne peut pas aider mes coéquipiers non-JS", tout serveur de maquette basé sur HTTP le résout. Pour une perspective frontend plus large, voyez comment les équipes gèrent la simulation d'API en React avec Axios.
Questions fréquemment posées
MSW est-il gratuit ?
Oui. Mock Service Worker est open source sous licence MIT et gratuit à utiliser dans tout projet, commercial ou non. Vous ne commencez à payer que lorsque vous passez à une plateforme hébergée pour des maquettes partagées, et des outils comme Apidog incluent également un niveau gratuit pour cela.
Apidog peut-il remplacer MSW dans mes tests unitaires ?
Non, et vous ne devriez pas essayer de le faire. MSW intercepte les requêtes au sein de votre exécuteur de tests JavaScript. Apidog est une plateforme hébergée, pas une bibliothèque importable, il ne peut donc pas se placer à l'intérieur de Jest ou Vitest comme le fait MSW. Utilisez Apidog pour les maquettes partagées, inter-équipes ou basées sur des schémas. Si vous vous concentrez uniquement sur le côté exécuteur de tests, ce guide sur la manière de simuler des appels API couvre les approches "in-code".
MSW fonctionne-t-il dans Node, ou seulement dans le navigateur ?
Les deux. Dans le navigateur, MSW utilise un Service Worker. Dans Node, il modifie la couche de requête pour que les mêmes gestionnaires s'exécutent dans Jest, Vitest ou tout environnement de test Node. Ce mode dual est l'une de ses plus grandes forces pour les équipes JS full-stack.
Quand devrais-je passer de MSW à un serveur de maquette hébergé ?
Passez à un serveur de maquette hébergé, ou plutôt ajoutez-en un, lorsque la maquette doit être partagée. Les signaux les plus clairs : un client non-JavaScript en a besoin, plusieurs personnes ont besoin de la même URL stable, ou vous concevez des API en commençant par les spécifications et souhaitez que les maquettes soient générées automatiquement à partir d'OpenAPI.
Conclusion
MSW est excellent pour ce pour quoi il a été conçu : intercepter les requêtes en JavaScript pour les tests frontend et unitaires. Il n'essaie pas d'être une maquette partagée, hébergée et agnostique au langage, et c'est très bien. Lorsque vos maquettes doivent sortir du dépôt, lorsque d'autres langages ou d'autres équipes en ont besoin, ou lorsque vous souhaitez qu'elles soient générées à partir d'une spécification, c'est le moment d'ajouter une plateforme complète à ses côtés.
Apidog gère le côté partagé et basé sur les schémas : un serveur de maquette hébergé avec une URL réelle, des maquettes automatiques à partir de votre conception OpenAPI et des données réalistes prêtes à l'emploi. Gardez MSW là où il est fort, et laissez Apidog couvrir tout ce qui dépasse les limites de votre exécuteur de tests. Téléchargez Apidog et dirigez votre frontend vers une maquette partagée pour voir la différence.