Does advice to avoid request assertions apply to server-side tests?

[thw0rted]

I just started using msw to test a Node REST service backend. The service is stateless, receiving inbound requests and generating a series of outbound fetch requests before responding. I have set up handlers that replicate responses from downstream services, and so far it works out really well.

I'm getting hung up on one thing, though. Tests from before we switched to msw often made assertions against POST bodies. Previously, we would have written something like

it('reformats the name parameter', async () => {
  await createFoo({name: 'ABC 123'});

  expect(mockFetch.calls[0][1].method).toBe('POST');
  // uppercase letters and space are not allowed
  expect(mockFetch.calls[0][1].body).toBe({name: 'abc_123'});
});

I'm simplifying things a bit, but you get the idea. Our service acts as a sort of "translation layer" between other services and we need to test that the translation is correct. If I don't do that by making expectations against the POST body, what's the "right" way to do it instead?

I did find #866 and the docs that are linked there, with an example of how to check request details using lifecycle events, but before I start down that path, I wanted to make sure I'm not setting myself up for failure later.

[kettanaito]

Hi, @thw0rted.

As a good place to start, I recommend reading through Request assertions. MSW generally discourages those since they often lead developers astray from testing what actually matters (the state/UI derived from the correct requests/responses).

If you are testing a service that's an intermediate layer and doesn't have any direct state to assert, then I recommend looking into Life-cycle events to track and assert the response, or implementing the following pattern:

import { DeferredPromise } from '@open-draft/deferred-promise'
import { server } from './your-msw-setup'

it('reformats the name parameter', async () => {
  const responseBodyPromise = new DeferredPromise()

  // Await the mocked response for the resource requested in "createForm".
  server.events.on('response:mocked', (response, request) => {
    if (request.url.pathname === '/resource/you/requested') {
      responseBodyPromise.resolve(JSON.parse(response.body))
    }
  })

  await createForm({ name: 'ABC 123' })

  // Assert the awaited mocked response.
  const actualResponseBody = await responseBodyPromise
  expect(actualResponseBody).toEqual({ name: 'abc_123' })
})

You don't have to use DeferredPromise to make this work but I like how it simplifies awaiting things in a different closure. You can use regular Promise as well.

[thw0rted]

Thanks, your example is pretty much what I wound up doing, based on the "wait" function in the lifestyle event docs. Instead of the Deferred pattern, I was able to use Promise.all to await the response and the function under test at the same time. Deferred is probably easier to follow, though, so I may switch.

Do you think it's worth a note in the docs, giving stateless services as another example where response assertions may be necessary?

[kettanaito]

I believe it's mentioned in Life-cycle events API. If it's not, I will add it to the next version of the docs.