Mock Service Worker (MSW)

Visit Website

Introduction

Mock Service Worker (MSW) is an API mocking library for browsers and Node.js. Instead of replacing fetch or your HTTP client with fakes, it intercepts requests at the network level and answers them with mocked responses, so your application code and tests stay unaware of whether a response is mocked.

Its README lists three ideas. Seamless: a dedicated layer of request interception keeps the app unaware of mocking. Deviation-free: the app requests the same resources it would in production, so you test real behaviour. Familiar and powerful: Express-like routing with parameters, wildcards and regular expressions, responding with any status codes, headers, cookies, delays or custom resolvers.

In the browser, MSW uses the Service Worker API, which the README calls the feature that sets it apart: mocked responses still appear in the browser’s DevTools network tab, which makes local development and demos realistic. In Node.js it uses request interception for test runners such as Vitest and Jest. The same handler definitions can be shared across both, plus Storybook and other tools.

In the quality loop, MSW covers unit and integration tests of front-end and Node.js code, prototyping against APIs that do not exist yet, and reproducing edge cases such as slow responses or server errors on demand.

The source code is at mswjs/msw on GitHub under the MIT licence, with about 18,300 stars; the most recent commit was on 11 November 2026.

How it compares: older approaches mock at the module level (for example jest.mock('axios')) or patch Node’s HTTP module (as Nock does). Module mocks couple tests to the HTTP client you happen to use, so switching from Axios to fetch breaks every test. MSW mocks the network itself, so the client can change without touching the mocks. Compared with standalone mock servers such as WireMock or json-server, MSW runs in-process with no extra server to start, which keeps unit tests fast and self-contained. The trade-off is that it only helps JavaScript code; polyglot teams often use MSW for front-end tests and a language-neutral mock server for backend integration tests.

Features

1. Network-level interception: Mocks requests made by fetch, Axios and other clients without changing application code.
2. Browser and Node.js: setupWorker for browsers and setupServer for Node.js, sharing the same request handlers.
3. REST handlers: http.get, http.post and others with path parameters, wildcards and regular expressions.
4. GraphQL handlers: Match queries and mutations by operation name and return typed data or errors.
5. WebSocket support: Intercept and mock WebSocket connections and messages, as covered in the docs and courses.
6. Runtime overrides: server.use() adds per-test handlers, for example to simulate a 500 error in one test only.
7. Realistic responses: Status codes, headers, cookies, delays and streaming responses.
8. Visible in DevTools: In the browser, mocked requests show up in the network tab like real ones.

Pros

1. Reusable mocks: One set of handlers serves unit tests, local development, Storybook and demos.
2. Free to use: Open source under the MIT licence, so the core tool costs nothing to use.
3. Actively maintained: The repository had commits as recent as 11 November 2026.
4. Community: About 18,300 GitHub stars.

Cons

1. Service Worker setup: Browser usage requires generating and serving the worker script, which can trip up some build setups and HTTPS rules.
2. Major-version migrations: API changes between major versions require updating handlers.
3. Not a contract test: Mocks can drift from the real API unless you check them against a schema or contract.
4. JavaScript only: Other languages need tools such as WireMock or Mountebank.

Usage and Links (Example)

Install and define handlers once:

npm install --save-dev msw

// mocks/handlers.js
import { http, HttpResponse } from "msw";

export const handlers = [
  http.get("/api/user", () => HttpResponse.json({ id: 1, name: "Ana" })),
];

Use them in Node.js tests (Vitest or Jest):

// test/setup.js
import { setupServer } from "msw/node";
import { handlers } from "../mocks/handlers";

export const server = setupServer(...handlers);
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Override a handler in one test to simulate an error:

server.use(http.get("/api/user", () => new HttpResponse(null, { status: 500 })));

For the browser, run npx msw init public/ and start the worker with setupWorker(...handlers).start() in development builds only.

Practical tips:

1. Keep handlers next to your API types so they evolve together.
2. Set onUnhandledRequest: "error" in tests so unexpected calls fail loudly.
3. Validate mock data against your OpenAPI or GraphQL schema to reduce drift.

Resources:

• Mock Service Worker (MSW) website
• GitHub repository
• Documentation
• Quick start
• Examples

Pricing

Mock Service Worker (MSW) is free and open source under the MIT licence.

Recommended for?

1. Front-end teams testing data-fetching components and hooks.
2. Node.js teams mocking third-party HTTP APIs in tests.
3. Teams building against unfinished backends, who need realistic mocks in the browser.
4. Not a fit for non-JavaScript stacks or for contract verification on its own.

Conclusion

MSW has become a default choice for API mocking in JavaScript because it mocks at the network boundary, not inside your code, and works the same way in browsers and Node.js.

Pair it with Testing Library for component tests and with contract or schema checks so your mocks stay honest.