Support Ukraine 🇺🇦 Support Ukrainian Military to Win The War.
LOGOMock Service Worker

Frequently asked questions

How is it different than library XYZ?

Please see the Comparison page for detailed technical and conceptual comparison between Mock Service Worker and other popular API mocking libraries.

In a nutshell, most solutions provide requests interception on the application level, while Mock Service Worker intercepts requests on the network level. It also allows you to use the same mock definition not only for testing, but for development and debugging as well.

Does it support library XYZ?

Yes. All request-issuing libraries are supported.

Be it axios, react-query, or plain fetch—Mock Service Worker supports all libraries that issue requests in both browser and NodeJS.

Can I use it with Node?

Yes.

Mock Service Worker provides a Node-compatible API to allow you to reuse the same mocking logic in a Node environment (for example, for testing).

Integrate with Node/docs/getting-started/integrate/node

Can I use it with React Native?

Yes, but because MSW relies on running a Node process, it can only be used for local development in the simulator or running unit/integration tests.

Since React Native does not support certain Node.js globals, like URL, you will need to add polyfills to patch the global environment by adding react-native-url-polyfill and import { setupServer } from 'msw/native'. For running unit/integration tests, use import { setupServer } from 'msw/node'.

Please see the following page for the integration steps:

Integrate with Node/docs/getting-started/integrate/node

Is this library secure?

Yes.

Mock Service Worker uses Service Worker API for requests interception. That API is implemented by a browser according to the Service Worker specification, making the library as secure as the worker's implementation itself.

Moreover, you are in full control over the Service Worker's code (mockServiceWorker.js), because you copy and serve it manually.

Learn more about Service Worker security from Google.

Should I commit the worker script to Git?

Yes.

We highly recommend committing the mockServiceWorker.js file to Git. That way all the collaborators would have the same mocking behavior, ensuring consistent experience across the team.

Alternatively, you can generate the Service Worker file by executing npx msw init as a part of your development pipeline.

Why do I see the "Detected outdated Service Worker" error in my console?

The worker script (mockServiceWorker.js) that you've instantiated is a part of your application just as any other JavaScript module. However, it's also an artifact of the library and MSW may issue occasional updates and bug-fixes to the worker script. In order for you to see that the update is needed, we're running an integrity check between your currently active worker and the latest one (based on the installed version of MSW).

We understand that the integrity check error may be disruptive to your process, and highly recommend providing the worker directory path in your package.json under the msw.workerDirectory path:

1{
2 "name": "your-app",
3 "msw": {
4 "workerDirectory": "public"
5 }
6}

When present, this property will be used whenever you install the msw package to automatically update the worker script at the specified directory.

You can also use the msw init command to save the worker directory automatically:

init (CLI)Instantiate a new worker script.

Why should I drop query parameters from a request handler URL?

Request handler URL represents a server-side resource path, similar to how you would describe that resource on an actual server. Since query parameters do not describe the resource path, but rather provide additional data to a resource, they cannot affect request matching and must be omitted when providing a request URL.

1- rest.get('/user?id=abc', resolver)
2+ rest.get('/user', resolver)

It is still possible to access query parameters and build the mocking logic around them in the response resolver.

Why do I get stale responses when using React Query/SWR/etc?

Caching mechanism of some request clients may produce stale responses in your tests. Make sure you clear the cache before/after each test suite for your tests to remain predictable.

React Query

1import { QueryCache } from 'react-query'
2
3const queryCache = new QueryCache()
4
5afterEach(() => {
6 queryCache.clear()
7})

SWR

To reset the SWR cache between test cases, simply wrap your application with an empty cache provider. Here's an example with Jest (copied from the SWR docs):

1describe('test suite', async () => {
2 it('test case', async () => {
3 render(
4 <SWRConfig value={{ provider: () => new Map() }}>
5 <App/>
6 </SWRConfig>
7 )
8 })
9})

It's recommended to integrate the <SWRConfig /> provider into a custom render function to avoid unnecessary code duplication.

Apollo Client

1import { client } from '../lib/apolloClient'
2
3beforeEach(() => {
4 return client.cache.reset()
5})

The exact API for clearing cache may differ depending on your request client. Please refer to your request client's documentation for more details.