Testland
Browse all skills & agents

msw-handlers

Authors Mock Service Worker (MSW) request handlers for both browser and Node.js test environments using the `http.get` / `http.post` / `HttpResponse.json` API, wires them via `setupWorker` (browser) or `setupServer` (Node), and manages the test lifecycle (`server.listen` / `resetHandlers` / `close`). Use when the project uses JavaScript / TypeScript and needs to mock fetch / XHR at the network layer for both Vitest / Jest unit tests and Cypress / Playwright integration tests.

Install with skills.sh (any agent)

npx skills add testland/qa --skill msw-handlers
View source

msw-handlers

Overview

Mock Service Worker (MSW) intercepts HTTP requests at the network layer using Service Workers in the browser and a request- interception adapter in Node.js (msw-getting-started (opens in new window)). The same handler set works for both - the test author writes one http.get mock and uses it from Vitest unit tests AND from a Cypress browser test.

When to use

  • The project is JavaScript / TypeScript.
  • Tests need to mock HTTP at the same layer as the SUT - intercepting actual fetch / XHR calls rather than stubbing the HTTP client library.
  • Both browser tests (Cypress / Playwright) and Node tests (Vitest / Jest) need the same mock data - MSW's cross-environment consistency is its key advantage.
  • The team wants per-test handler overrides (server.use(...)) layered on top of project-wide defaults.

If the project is JVM, use wiremock-stubs. For multi-protocol mocking (TCP / SMTP / LDAP / gRPC), see the Mountebank reference in wiremock-stubs.

Install

npm i msw --save-dev

(Per msw-getting-started (opens in new window).)

For browser setup, also generate the worker script:

npx msw init public/ --save

This places mockServiceWorker.js in your public directory; the worker script is what the browser registers to intercept requests.

Authoring handlers

Per msw-getting-started (opens in new window):

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

export const handlers = [
  http.get('https://api.example.com/user', () => {
    return HttpResponse.json({ id: 'abc-123', firstName: 'John' });
  }),

  http.post('https://api.example.com/orders', async ({ request }) => {
    const body = await request.json();
    return HttpResponse.json({ order_id: 42, ...body }, { status: 201 });
  }),

  http.get('https://api.example.com/orders/:id', ({ params }) => {
    return HttpResponse.json({ order_id: Number(params.id), status: 'shipped' });
  }),
];

Handler signature: http.<verb>(url, resolver). The resolver receives { request, params, cookies } and returns an HttpResponse.

HttpResponse static helpers

HelperEffect
HttpResponse.json(body, init?)JSON response with Content-Type: application/json.
HttpResponse.text(body, init?)Plain text response.
HttpResponse.error()Network-level error (e.g. simulate offline).
new HttpResponse(...)Full-control raw response.

The init object accepts status, statusText, headers - matching the standard Response API.

Pattern matching

PatternNotes
'https://api.example.com/orders/:id'Path param exposed via params.id.
'/api/orders'Same-origin path; matches relative to current host.
'*\\/orders'Wildcards via standard URL pattern.
/^\\/api\\/orders\\/[0-9]+$/Regex match.

Browser setup - setupWorker

// src/mocks/browser.js
import { setupWorker } from 'msw/browser';
import { handlers } from './handlers';

export const worker = setupWorker(...handlers);

// Start the worker only in development / test
if (process.env.NODE_ENV !== 'production') {
  worker.start();
}

(Per msw-getting-started (opens in new window).)

In a Storybook + MSW combo, kick off worker.start() from the preview file. For Cypress: register the worker before any test that depends on the mocks.

Node setup - setupServer

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

export const server = setupServer(...handlers);
// vitest.setup.js (or jest.setup.js)
import { server } from './src/mocks/node';

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

(Per msw-getting-started (opens in new window).)

HookWhenPurpose
server.listen()beforeAllActivate mocking.
server.resetHandlers()afterEachClear per-test overrides.
server.close()afterAllTear down; release resources.
server.use(...)Per-testAdd / override handlers for the current test only.

onUnhandledRequest: 'error' is the canonical strict mode - fails the test if the SUT makes any HTTP call that doesn't have a matching handler. Catches "we forgot to mock that endpoint" silently passing.

Per-test handler overrides

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

test('handles 500 error gracefully', async () => {
  server.use(
    http.get('https://api.example.com/user', () =>
      new HttpResponse(null, { status: 500 })
    )
  );

  const result = await fetchUser();
  expect(result.error).toBe('server error');
});
// `server.resetHandlers()` in afterEach reverts to the default handlers

This pattern is the canonical way to test error / edge paths without polluting the default-handlers set.

CI integration

# .github/workflows/test.yml
- run: npm ci
- run: npm test          # Vitest / Jest pick up vitest.setup / jest.setup automatically

For Cypress + MSW, also run npx msw init in CI to ensure the service worker script is in public/.

Anti-patterns

Anti-patternWhy it failsFix
onUnhandledRequest: 'bypass' (the default before strict mode)Test passes despite the SUT calling unmocked endpoints; real network bleeds in.Always 'error' in CI.
Per-test handler definition (no shared handlers.js)Duplication; drift between tests; hard to maintain.One handlers.js per project; server.use() for overrides.
Forgetting resetHandlers()Handlers leak across tests; later test fails because earlier test's override is still active.Always afterEach(() => server.resetHandlers()).
Using MSW for tests that exercise network errors onlyMSW intercepts at HTTP; for low-level network errors, use HttpResponse.error() or simulate via the test framework.The two are different layers; MSW handles HTTP, lower errors need other tooling.
Mocking the same endpoint in browser AND node setups separatelyDrift; bug fix in one is missed in the other.Single handlers.js consumed by both setupWorker and setupServer.
Including MSW in the production bundleBloat; possibly leaks mocks to real users.Tree-shake by importing only in process.env.NODE_ENV !== 'production' branches; never import { worker } at top level.

Limitations

  • Service Worker scope. Browser MSW only intercepts requests from the same origin / path scope as the worker registration. Cross-origin requests need explicit handler URLs.
  • Streaming responses. SSE / chunked responses work but are more delicate than JSON; consult MSW docs for the streaming API.
  • No native scenario state. Stateful workflows ("after POST, GET returns the new item") need to manage state in your handlers manually (e.g. with a closure-scoped variable).

References

  • msw-getting-started (opens in new window) - install, handler authoring, browser vs node setup, lifecycle hooks, server.use() per-test overrides.
  • MSW Docs - https://mswjs.io/docs/
  • wiremock-stubs - JVM counterpart; its references/mountebank.md covers the multi-protocol alternative.

Related skills

boundary-value-generator

Generates boundary-value test cases from typed input specifications - for each input field, produces the canonical 6-point set (one below, at, and above the lower bound; one below, at, and above the upper bound) plus equivalence-class representatives. Emits cases as parameterized test inputs (pytest @parametrize / Jest test.each / xUnit InlineData / etc.). Use when a function or endpoint has numeric / string-length / collection-size constraints and the team needs systematic edge-case coverage.

faker-data

Fixes test data that breaks tests - factory values in a shape the code under test rejects (a phone number that is not E.164), fixtures that only pass when the whole suite runs in order, and random values that make an assertion pass or fail depending on the run. Authors test-data factories with Faker: the Python `faker` library, the `@faker-js/faker` JS port, and the `faker-ruby` gem - install per language, the provider catalogue (person / internet / location / date / finance / lorem), locale selection and multi-locale mode, and seed-based determinism for reproducible runs. Scope is generating fresh values for tests that start from nothing, not replacing values inside a dataset that already holds real records - that goes to pii-masking-pipeline-builder. Use when fixtures need realistic values, a stable shape, or a fixed seed.

golden-file-conventions

Reference catalog for snapshot / golden file management - naming conventions, directory layout, when to add / update / remove a baseline, sanitization (timestamps, IDs, PII), per-OS / per-runtime variant strategy, and review workflow for snapshot diffs in PRs. Use when designing a snapshot-testing convention or auditing an existing one for drift.

malicious-payload-bank

Reference catalog of curated adversarial input payloads keyed by attack class - SQL injection, XSS, SSRF, path traversal, command injection, XXE, prototype pollution, regex DoS, Unicode confusables, header injection - plus per-context guidance for which payloads apply (URL parameter / form input / JSON body / file upload). Use when authoring negative-test cases for input validation, fuzz targets, or a security-focused test suite that needs to exercise the OWASP Top 10 attack surface.

negative-test-generator

Covers the refusal paths a handler already implements but nothing tests - a batch endpoint that must apply all rows or none, optimistic-concurrency version conflicts between two editors, or a delete that deliberately separates who you are from what you may do from the state the record is in. For each happy-path test, produces companions exercising input validation rejection, missing required fields, type mismatches, authorization failures, rate-limit errors, and adversarial payloads from the malicious-payload-bank, emitted as parameterized tests in the project's runner format. Use when code has deliberate error paths and the suite only proves the success case.

pairwise-test-case-generator

Generates parameterized test inputs combining boundary-value, equivalence-class, and pairwise-combinatorial cases from a typed multi-input specification - produces the cross-product of cases up to a configurable strength (1-wise / 2-wise / N-wise) using all-pairs reduction so the test surface stays tractable. Emits cases in the project's test-runner-native parametrize format. Use when a function or endpoint takes 3+ inputs whose interactions matter and full Cartesian product would explode.

seed-data-curator

Builds a reproducible E2E seed dataset for the project's test environments - picks a representative user / org / data-product cross-section, generates the rows via the project's chosen factory library (FactoryBot / mimesis / Bogus / Faker + factory_boy), persists the dataset as a checked-in fixture (SQL dump / JSON / per-engine seed file), and wires it into the test bootstrap. Use when starting E2E coverage on a project that has no seed strategy, or when an existing seed has drifted.

synthetic-data-toolkit

Umbrella for the synthetic test data generators beyond plain Faker - FactoryBot (Ruby factories with traits, associations, and build / create / build_stubbed strategies), Mimesis (fast type-hinted Python generator with the Schema/Field bulk pattern and 46 locales), and Bogus (.NET typed `Faker<T>` builders with `.RuleFor` / `StrictMode` / `UseSeed`). Picks the right generator by language and job, shows side-by-side equivalents of the same fixture across all four ecosystems, and carries each tool's full workflow in references/ (factory-bot.md, mimesis.md, bogus.md). faker-data stays the default for plain field values in Python / JS / Ruby; use this skill when the project needs typed factory orchestration, .NET fixtures, or a documented "which tool should I use" decision.

synthetic-pii-generator

Generates realistic-but-fake personally identifiable information (PII) - emails, phone numbers, SSNs / national IDs, addresses, names, credit-card numbers (test BIN ranges), date-of-birth - for non-production environments. Wraps Faker / mimesis with PII-aware constraints so generated values match real format expectations (Luhn-valid card numbers, region-valid phone formats, ITIN/SSN format) without ever generating real-person data. Use when seeding test environments, building demo data, or replacing real PII in copied datasets.

test-data-patterns

Pure reference catalog of the cross-language object-construction patterns for test data - Test Data Builder (Pryce/Freeman), Factory (with traits and associations), Object Mother, Fixture composition (per-test / per-describe / shared), Snapshot (defers to `golden-file-conventions` for the operational details), and Production-Data Anonymisation. Distinct from the per-language tool skills (`faker-data` and the `synthetic-data-toolkit` umbrella covering FactoryBot / mimesis / Bogus) which document tool-specific configuration; this catalog is the architecture-tier reference for choosing **which pattern** before reaching for the tool. Use when choosing a test-data construction pattern for a new suite, or auditing an existing suite whose fixtures have drifted into shared mutable state.

wiremock-stubs

Authors WireMock stub mappings for HTTP service mocking - `stubFor` with verb/path/header matchers + `willReturn` response shaping, lifecycle via `WireMockServer` (start / stop) or JUnit `WireMockExtension`, request verification via `verify()`, and dynamic-port allocation for parallel tests. Also carries the Mountebank multi-protocol workflow (TCP / SMTP / LDAP / gRPC imposters, record-playback proxying) in references/mountebank.md. Use when the project is JVM-based and tests need to mock HTTP dependencies (third-party APIs, internal microservices) at the network layer, or when mocking must go beyond HTTP.