How do you mock different responses in real life?

[antoinerey]

👋 Hello hello!

I'm kinda new to this mocking thing, and I'm struggling implementing a proper developer experience to test different cases. Let's take the following scenario for example: a user wants to browse our home page, which fires a requests to our API.

flowchart LR
  User -- browse --> /home
  /home -- calls --> /api/articles/latest

Note that the endpoint is static, meaning that we do not pass any path param, query param, custom headers, etc. Every request to the home page will fire the exact same API request. Nothing changes on that side.

---

However, I'd still like to mock different responses:

1. The "happy" path, where everything works as expected.
2. The "sad" path, where the endpoint returns a server error.

So, here are what my handlers could look like:

export const handlers = [
  rest.get('/api/articles/latest', (request, response, context) => {
    // Sad path
    if (...) {
      return response(
        context.status(500),
        context.json({ error: 'oops!' }),
      )
    }

    // Happy path
    return response(
      context.status(200),
      context.json({ data: 'some-random-fake-data' }),
    )
  }),
]

---

And, we're approaching what I'm struggling with: What to define as if condition to respond with different mocks?

Since the API call is entirely static, I can't use anything to differentiate both of them. One way, would obviously be to add such dynamic parameter, but it would introduce something that will only be used to test the application, and never in production. Which does not look great in my opinion.

So, here I am, asking the community for advice. How do you handle such cases on your side? Is there another solution that I didn't think of?

🙏

[kettanaito]

Hey, @antoinerey. Thanks for raising this, it's a great question.

One great thing is that the handlers you write are still regular JavaScript code executed on the client. This means they have the entire client context, not only the intercepted request. I've seen a great pattern where developers controlled what API responses MSW returns by using the URL query parameters:

export const handlers = [
  rest.get('/api/articles/latest', (request, response, context) => {
    const pageParams = new URLSearchParams(window.location.search)
    const scenario = pageParams.get('scenario')

    // Sad path
    if (scenario === 'error') {
      return response(
        context.status(500),
        context.json({ error: 'oops!' }),
      )
    }

    // Happy path
    return response(
      context.status(200),
      context.json({ data: 'some-random-fake-data' }),
    )
  }),

Note that scenario here analyzes the page URL, not the request URL. You can control what response MSW will use by loading your /home page with the correct ?scenario query parameter. For example, this will open the /home page and use the "Sad" scenario to respond to the intercepted request:

• http://localhost:3000/home?scenario=error

Since there's no request information to base the conditional mocked responses on, then the next upper context—like the /home page itself—may provide that information.

Node.js

If you want to make this endpoint respond with different mocked responses in a Node.js test, for example, use the server.use() function:

it('success path', () => {
  // no changes to the handler
})

it('error path', () => {
  server.use(
    rest.get('/api/articles/latest', (req, res, ctx) => res(ctx.status(500))
  )

  // the rest of the test
})

You can use worker.use() in the browser as well! That'd require you to append the handle on runtime—when viewing the page—if you wish.

[kettanaito]

But unfortunately, I can't retrieve the URL of the page being generated on node.js side.

Not sure what you're referring to here. The URL of the page is retrieved on runtime, right in the browser. I suppose there's some additional build step in your case that takes place? Even so, it shouldn't be a problem, all build tools run in Node.js but produce JavaScript that can run in the browser.

[sunpietro]

Unfortunately, this answer is correct for the browser handlers only. For the server handlers it doesn't work at all because of 2 things:

1. on server side the window object is not accessible,
2. the request object does not contain any information where the request was sent from, so setting the search query param is a no-go solution.

I keep looking for other solutions, because it feels msw.js is limited in terms of differentiating request responses when requests are sent on SSR like from the getServerSideProps function.

[kettanaito]

Hey, @sunpietro. I believe there's been a confusion about this. Let me clarify.

on server side the window object is not accessible,

That is correct if we're speaking about running MSW in pure Node.js. If that's the case, you don't need window since all request URLs are absolute in Node. You cannot construct a relative URL because there's nothing to be relative to.

Neither do you have to persist MSW globally using window. MSW instantiates within the same process, so it's always available. Just move it to a standalone module and export the server from it.

// mocks/server.js
import { setupServer } from 'msw/node'

export const server = setupServer()

Now you can import { server } from anywhere in your Node.js process and use server.use() to prepend any behavioral overrides on demand.

the request object does not contain any information where the request was sent from, so setting the search query param is a no-go solution.

MSW doesn't alter requests in any way. If there's no information about the sender, take a look if you're sending that information in your implementation, to begin with. If you do, it will appear in the intercepted request accordingly.

[yaswanthmaddula-sureify]

I wanted to use MSW to mock apis for my test cases. So the process runs in NodeJS. If I have to set a query param scenario, I need to edit my application code for the same, which is not a good practice. I am using Create React App with react testing library and jest. What are my options ?

[kettanaito]

@yaswanthmaddula-sureify, in Node.js, you don't have to do anything regarding query parameters (those don't exist in Node.js anyway). Follow my suggestion above:

1. Integrate MSW in Node.js.
2. Import the server object in any of your tests.
3. Use Runtime request handlers (i.e. server.use()) to add and override any network behavior you want.

Here's an example: I want a GET https://example.com/user request to fail only for a particular test. This is how I use server.use() to achieve that:

// particular.test.js
import { http, HttpResponse } from 'msw'
import { server } from './your/server/integration'

// Don't forget to reset any handlers you add via ".use()"
// so they don't affect the network in irrelevant tests. 
afterEach(() => server.resetHandlers())

it('handles 500 responses', async () => {
  // Do this override as the first thing in your test.
  server.use(
    http.get('https://example.com/user', () => new HttpResponse(null, { status: 500 })
  )

  // ...continue with your test
  // (render the app that makes that GET request.
  // Now, it will always produce 500. 
})

[fvanwijk]

@antoinerey I had exactly the same issue, but solved it differently.

Instead of hardcoding the different scenarios in the mock handler, you could define different handlers and switch between them on runtime.

I created a package that solves this problem for you:
MSW dynamic HTTP middleware

It cannot leverange MSW as being a service worker inside your app, but it reuses the response composition features of MSW.

[fvanwijk]

You cannot test in parallel indeed, because the mock server is stateful and runs next to the application that you are testing. So the application will be tested in parallel but there is still one mock server. Technically you could spin up a mock server per parallel thread, but that requires some additional work.

In a unit test you can still use MSW Node.js and for E2E testing I try to make then not run for too long anyway (testing pyramid/trophy) so I never need parallelization. For quick scenario switching in Cypress I call cy.setScenario('scenarioname').

You have to add this to commands.ts:

Cypress.Commands.add('setScenario', { prevSubject: false }, (scenarioName) =>
  cy.log(`Set scenario "${scenarioName}"`).request({
    method: 'PUT',
    url: 'http://localhost:9800/scenario',
    body: { scenario: scenarioName },
    log: false,
  }),
);

Cypress.Commands.add('resetScenarios', { prevSubject: false }, (resetAll) =>
  cy.log('Reset MSW Server').request({
    method: 'DELETE',
    url: `http://localhost:9800/scenario${resetAll ? '?resetAll=true' : ''}`,
    log: false,
  }),
);

@kettanaito What's you opinion about migrating my package into the @mswjs scope, like you also did with http-middleware? Do you think it could part of the mswjs core ecosystem or would be better to leave it a package in user space like it is right now?
We could add a section the FAQ or a recipe "Changing responses on runtime" that addresses this specific problem, because I think many developers stumble upon this case after a while.

[fvanwijk]

@kettanaito Some time has passed and I think msw-http-dynamic-middleware still proves its value (at least in my projects), so I wonder if you're open for moving it into the @mswjs scope

[kettanaito]

@fvanwijk hi. I fell out of this discussion for some time. Let me check the package and see how we could integrate it in the ecosystem. 👀

[fvanwijk]

@kettanaito Thanks, I'm looking forward to your verdict

[kettanaito]

Hey, @fvanwijk. So, regarding the msw-http-dynamic-middleware package, I still think it's too specific to be recommended broadly. You can still use and promote it, as I certainly will, to whomever is facing the same challenges as you.

Regarding the Cypress extension, now that is something I think MSW should have an ecosystem package for. There's a demand for Playwright extension as well, so we can have packages like @mswjs/extend-cypress and @mswjs/extend-playwright to make MSW integration with those tools a bit easier.

My only concern is that I need champions for those packages. People who will maintain them. If you think you can do that, I'd be thankful, and we could move forward with that. Let me know.

[coler-j]

How do you test GQL that calls the same query or mutation multiple times in the same test (with the same or no args)?

[kettanaito]

Hey, @coler-j.

Since all those requests will hit the same request handler, and you don't have any payload to distinguish them (different headers/parameters/body), then you'd have to track their call order.

You can do that by declaring your response resolver as a generator function:

import { graphql } from 'msw'

export const handlers = [
  graphql.query('GetPosts', function* (req, res, ctx) {
    let requestNumber = 1
    const data = getDataByRequestNumber(requestNumber)
    requestNumber++

    yield res(ctx.data(data))
  })
]

You can take a look at our integration test for inspiration. I'm not proficient with generators, so perhaps you'd have to issue a regular return at some point.

[SSERVOUZE]

I ended up going for the generator function response resolver as well which is pretty brilliant to me 👍

[coler-j]

Thanks, that is what I ended up doing.

…

On Mon., Jul. 11, 2022, 5:43 p.m. Artem Zakharchenko, < ***@***.***> wrote: Hey, @coler-j <https://github.com/coler-j>. Since all those requests will hit the same request handler, and you don't have any payload to distinguish them (different headers/parameters/body), then you'd have to track their call order. You can do that by declaring your response resolver as a generator function: import { graphql } from 'msw' export const handlers = [ graphql.query('GetPosts', function* (req, res, ctx) { let requestNumber = 1 const data = getDataByRequestNumber(requestNumber) requestNumber++ yield res(ctx.data(data)) })] You can take a look at our integration test <https://github.com/mswjs/msw/blob/6990c3a57a1f515fe977c2eaa7741005b885b8af/test/rest-api/generator.mocks.ts#L4> for inspiration. I'm not proficient with generators, so perhaps you'd have to issue a regular return at some point. — Reply to this email directly, view it on GitHub <#1117 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3Z672TAAZV72MFW7ECTJDVTSIRVANCNFSM5PEZFFMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vietanhtran16]

I find the marked answer really helpful thanks for that 👍. One question though, below is our set up and we want to achieve similar ideas with setting scenario as a query string which is then used to switch between scenarios for our upstreams apis so that we dont have to spin up our upstreams (mocking the fetch from our BFF to upstreams with msw). Is that possible? I guess we would need to forward the query string from FE to the fetch that is calling our upstreams to make it work?

[kettanaito]

I'm not sure I fully understand but it looks like you want for the frontend to affect which upstream APIs your backend systems call. Is that correct? If so, then you can also pass some flag via headers (X-Use-Mock-Scenario or something). The setup on the server side will be very similar: setupServer + the logic that parses your flag and provides whichever subset of handlers you need.

[Bram-Zijp]

I am working on a project that will allow for making MSW mocks dynamic and allows you to create scenarios out of multiple dynamic mocks. It also includes a dashboard that is framework independent and does not resort to the MSW HTTP middleware. It has not been tested properly so I would not recommend using it just yet outside of proof of concepts.

It is a work in progress. The source code is still a bit messy/complex and barely has any documentation. The UI is not styled properly either and missing some functionality. As I see it now, the API should be pretty stable, apart from the setupWorker function. I will probably wrap up the initial version in a week or so.

I am just dropping this here in case anyone wants to keep track of it and perhaps share some early feedback or even contribute. https://github.com/dynamicmsw/dynamic-msw

[kettanaito]

That's a neat idea! Thanks for working on this. Let me know when you feel this is presentable, I can help you share it on Twitter.

[Bram-Zijp]

I will be busy in the coming weeks with my day job. Sharing it on twitter would be awesome! I will let you know when it's presentable.

[Bram-Zijp]

It's been a year and finally found some time/necessity to rewrite Dynamic MSW into something more maintainable and sane. Will be refactoring some parts but I'm really fond of the current API and dashboard. Check it out!
https://github.com/dynamicmsw/dynamic-msw

[velly]

parse the data from url or body. We can set up a set of test logic.
But what confuse me is request.json() that parsed _body return a promise？This is not friendly to us to return the Response Resolver?
Resolver has to return the response immedaitely.

[Bram-Zijp]

The return type of the rest/graphql handler is MaybePromise. You can make the function async and use await:

rest.post('http://localhost/xx', async (req, res, ctx) =>
    res(ctx.json(await req.json()))
)

test example:

import { setupServer } from 'msw/node';
import { rest } from 'msw';
import fetch from 'node-fetch';

test('example', async () => {
  const server = setupServer(
    rest.post('http://localhost/xx', async (req, res, ctx) => {
      const data = await req.json()
      res(ctx.json(data))
    })
  );
  server.listen();
  const data = await fetch('http://localhost/xx', {
    method: 'POST',
    body: JSON.stringify({ hello: 'world' }),
  }).then((res) => res.json());

  expect(data).toEqual({ hello: 'world' });
  server.close();
});