Discussion on: Testing a Generic Fetch Item List hook with Mock Service Worker

[Cathal Mac Donnacha 🚀]

Hey @kettanaito

I love the server.use override in tests, very handy! However, how do you handle this in the browser? In that case you probably would have to use a global override as suggested above.

[Artem Zakharchenko]

Hey.
The browser has its worker.use() counterpart that behaves identically to server.use(). You can still leverage "happy path" scenarios provided to the setupWorker() call, and then append runtime behavior via worker.use().

Yes, to be able to access the worker in the first place you'd have to expose it as a global variable.

[Cathal Mac Donnacha 🚀]

Thanks for the quick reply!

This might be a dumb question but can this then be used in chrome console window?

window.msw.rest.get(`*/cars`, (req, res, ctx) => {
  return res(ctx.status(500), ctx.json({error: 'Oops'}));
});

I just tried but still not seeing the error response, I assume my "happy path" worker which is running when my app loads in dev is overriding it. I basically just want an easy way to simulate error scenario while developing locally.

[Artem Zakharchenko]

Executing that in the browser console should apply the override. If it's not applied, double-check the correctness of the request path. When mocking on runtime, I find it much more comfortable to bind the handlers overrides to the URL query parameter.

1. Read the parameter in your mock setup.
2. Append certain handlers based on the parameter (can go as dynamic here as you wish: passing enums for handlers groups, or names of handler modules).

Since the handlers are loaded on runtime, refreshing that runtime will offload them forever. That's where URL-as-state is a more developer-friendly pattern but it takes some time to set up.

[Cathal Mac Donnacha 🚀]

Gotcha. The app I am currently looking at does not have react-router or anything similar implemented, so doesn't update the route or query string in the address bar url as the user clicks around. The app is also hosted on a different domain to the api. Therefore, what do you think about just reading the query string via the window location within the handler itself? Like this:

// Example url which developer would navigate to in the browser:
// http://localhost:3000/car-dashboard?error=true

rest.get(`/cars`, (req, res, ctx) => {
  const searchParams = new URLSearchParams(window.location.search);
  const isError = searchParams.get('error') === 'true';

  if (isError) {
    return res(ctx.status(500), ctx.json({error: 'Oops'}));
  }

   return res(ctx.status(200), ctx.json({results: mockCars}));
});

I'd probably use the same approach to simulate an empty state in the UI:

// Example url which developer would navigate to in the browser:
// http://localhost:3000/car-dashboard?error=false&empty=true

rest.get(`/cars`, (req, res, ctx) => {
  const searchParams = new URLSearchParams(window.location.search);
  const isError = searchParams.get('error') === 'true';
  const isEmpty = searchParams.get('empty') === 'true';

  if (isError) {
    return res(ctx.status(500), ctx.json({error: 'Oops'}));
  }

  if (isEmpty) {
    return res(ctx.status(200), ctx.json({results: []}));
  }

   return res(ctx.status(200), ctx.json({results: mockCars}));
});