Mock Service Worker (MSW) works by using a technology built into modern browsers called the Service Worker API. Think of a service worker as a proxy that sits between your web application and the network. It's a special kind of JavaScript file that the browser runs in the background, separate from your web page.

Because it acts as a proxy, it can intercept any outgoing network request your application makes, whether it's a fetch call, an Axios request, or even an image being downloaded via an <img> tag. Your application code doesn't know the service worker is there. It makes a request as it normally would, but the service worker catches it before it ever leaves the browser.

This network-level interception is the core principle of MSW. Your application operates exactly as it would in production, completely unaware that its requests are being handled by a mock server instead of a real one. This leads to much higher confidence in your tests.

Before MSW, the common way to mock requests was to find the specific function in your code that makes the request and replace it with a fake implementation. For example, you might use Jest's spyOn(window, 'fetch') to hijack the fetch function globally. Tools like Nock do something similar for Node.js environments by patching the native http module.

This approach works, but it has drawbacks. It's intrusive because you are modifying your application's runtime environment. Your test is no longer testing the real application code that sends the request; it's testing a mock. This can lead to tests that pass even when the application itself is broken. For example, your code might use Axios, but your test mocks window.fetch. The test would pass, but the actual application would fail.

MSW avoids this by operating at a completely different level. It doesn't touch your code. It intercepts the request after your code has already sent it, making the mock invisible to the application.

When a request is intercepted by MSW, it flows through a simple lifecycle. The service worker captures the request and checks it against a list of request handlers you've defined. These handlers are functions that specify how to respond to requests matching certain criteria, like the method (GET, POST) and the URL path.

If a matching handler is found, it executes and returns a mocked response. This response is then passed back to your application just as a real network response would be. If no handler matches the request, MSW lets it pass through to the actual network by default. This allows you to mock only the specific endpoints you care about for a given test.

To get started, MSW provides a CLI command to generate the service worker file for you. This file needs to be placed in your public assets directory so the browser can access it.

One of MSW's greatest strengths is its ability to work in any environment. This is possible through two separate entry points:

• msw/browser: Used for browser environments. It uses the setupWorker function to register and activate the service worker script we just initialised.
• msw/node: Used for Node.js environments, such as Jest tests, Storybook's Node process, or Next.js server-side rendering. It uses the setupServer function, which leverages a low-level library to intercept outgoing requests made by Node.

This dual-package approach allows you to write one set of request handlers and reuse them for component testing, end-to-end testing, local development, and even in your Storybook component library. The mocking logic is consistent everywhere.