Question: request handler request history

Is your feature request related to a problem? Please describe. When using msw in a test environment, I’d like to be able to retrieve history of requests / responses for a certain handler. Do they get stored anywhere? When using axios, there’s a way to do it if you use axios-mock-adapter, that provides history per method. Without mocking axios, I can’t find a way to retrieve the last request made so I can verify that a request with certain params had been made.

Given

export const findPets = (petResponse?: Pet[]) =>
  rest.get(`${endpoint}/pets`, (req, res, ctx) => {
    const PetResponse = petResponse ?? PetStub.buildList(10)

    return res(ctx.delay(0), ctx.status(200), ctx.json(PetResponse))
  })

PetsList.test

  it('should return n results when limit is set', async () => {
    const FindPets = findPets()
    server.use(FindPets)

    render(<PetsList />) // Component makes a request with a query param {limit: 2}
    await waitFor(() => screen.getByText(/List of pets/i))

    /* Here I'd like to be able to retrieve GET request and assess it's params so I could validate that component's sending proper params, a la
	expect(FindPets.history[0]).toEqual(expect.objectContaining({ limit: 2})
    */
  })

Additional context

Name	Version
msw	0.20.5
node	13
axios	0.19.2

[kettanaito]

Hey, @ilyaulyanov. Thanks for reaching out.

I’m afraid accessing such list and performing assertions on it would be implementation details testing. Instead of checking internals of MSW and looking up if some handler was called with some parameters, think of it this way: if a handler is called with invalid parameters, your React component’s output will be invalid. Assert what your component renders, not the network layer.

Take a look at the similar question that’s been raised recently. I go into details and provide usage examples that lean your test towards testing what matters.

I can see such API being useful only for development purposes. It brings too much temptation to test if something was called, or was called with the right parameters, which is something MSW actively discourages. Test how your component reacts to the response, emulate unsuccessful and error responses, provide conditional mocked responses based on the request parameters in your response resolvers—this will give you much more confidence in your tests.

Hope this helps.

[kettanaito]

@ilyaulyanov consider reusing the condition logic from the rest of your app. Since mocks execute in the same context, you can call the same validation functions in the mocks, for example, that you do in the actual application’s implementations. This is a solid way of ensuring you don’t get false positive/negative results in your tests.

Even though, the last bit of having to re-implement some parts of business logic (e.g. conditional response based on a value of a param) takes away from “realness” a bit.

It may feel like repetition, but in reality it’s depicting the behaviors that make your request valid. Not all business logic should be copied to response resolvers. The one that does helps you to reason about API changes over time, acting like a snapshot of an API contract once established. This is one of the arguments against any kind of sync between the actual server and mocks: it would destroy the reproducibility of a mock.

Thank you for the suggestion, I think it’s a good idea to put these recommendations into a recipe. I’ve added the Request assertions recipe, please take a look.