Allow asserting on requests

Is your feature request related to a problem? Please describe. We are currently migrating cypress integration tests (network mocked) to an app-level JSDOM integration tests, and chose MSW as the network-layer mock framework.

We cannot use MSW alone to test all our scenarios.

Describe the solution you’d like Ability to assert on network calls:

• What has been called.
• How many times.

Describe alternatives you’ve considered A different product (keep some tests in cypress), or spy on fetch.

A VERY Good Advice

From the docs:

Adding such assertions, however, is implementation details testing and is highly discouraged.

I think this is a VERY good advice (albeit with some reservations on the term “implementation details”, below).

Asserting requests in such way is testing how your application is written, instead of what it does.

This I disagree with because part of what our app does (ie, its behaviour) is calling some endpoints (see elaboration below).

There are various other related issues, including this one where @kettanaito wrote:

I’m afraid accessing such list and performing assertions on it would be implementation details testing.

See comment on “implementation details” below.

And then:

Assert what your component renders, not the network layer.

Agree with this. An excellent advice, albeit not always possible.

But

There is no such thing as context-free wisdom.

There aren’t always a side effects

Polling. We poll every X minutes and if the data hasn’t changed nor will the view. No side-effects (other than the network call).

The network is a test boundary

So in our case - app-level integration tests - there are two main boundaries:

• The UI (which we assert on)
• The network (which we cannot assert on with MSW).

There are other boundaries, like window.ga, localStorage, etc. But we can disregard them here.

As a test boundary, we would like to make some assertions on it.

Example

So we had a page test in Cypress, and through the command log we saw two, near-consecutive, network requests to the same endpoint. Turns out a component was re-rendering and firing twice a data-fetching request.

So we assert in the test that the endpoint should only called once.

The component was re-rendering due to other mocked network responses. So unit-testing the component wouldn’t catch this - only an app level realistic page load.

It isn’t implementing detail

You are always testing some implementation detail. Regardless of the level of your tests. Even an e2e test in cypress involves an implementation detail - it tests against a browser (if tomorrow the app is to run as a native app, you’ll have to modify the tests).

What is an implementation detail is contextual. It depends on the point of reference.

A low-level date formatter is an implementation detail for a table component that renders dates (think of a unit-test for that table component.

The very same table component is an implementation detail for the page containing it (think of testing the page).

At any point, whatever is below the interface you interface with is implementation detail.

So branding assertions on network calls “implementation details”, specifically when they are one of test boundary (ie, test interface), is somewhat not the best way to put it.

When the network is the testing boundary, hitting that boundary is what the system is doing as far as the tests are concerned. It isn’t implementation detail - what’s inside the box (the system between the network and UI) that is implementation detail here.

Make perfect sense to me you’d like to assert on network side-effects in some cases (whilst I do totally agree that doing so may not be a good practice in many cases - UI assertions should take precedence if possible).

Summary

So while I think it is a good advice, there are still some scenarios where request assertions are needed. I hope the team will re-consider.

[Dobby89]

You can make request/response-based assertions even today using the library’s Life-cycle events API.

This is exactly what we need. Not sure how I’ve missed that in the docs and other issues. Had I seen this before I would not have raised the ticket.

I really think this should be added as a note here: https://mswjs.io/docs/recipes/request-assertions. Happy to raise a PR.

@kettanaito I only found this issue because it wasn’t mentioned on that page. @Izhaki and I can’t be the only people.

[Izhaki]

You can make request/response-based assertions even today using the library’s Life-cycle events API.

This is exactly what we need. Not sure how I’ve missed that in the docs and other issues. Had I seen this before I would not have raised the ticket.

I really think this should be added as a note here: https://mswjs.io/docs/recipes/request-assertions. Happy to raise a PR.

MSW will not ship request assertions API, as it’s simply outside of the library’s responsibilities and promises it establishes with the end developer.

This makes a lot of sense - keep API surface low.

Just to be clear, I wasn’t after an assertion mechanism (like chai). I was after the ability to assert on network requests (which the life-cycle events allow).

This is a book-worth discussion about what and how to test

I feel we are 100% align on test good practices - I gave a tech talk last week pretty much arguing everything you argue here.

My point was that there are some cases where asserting on network request is valid.

Thanks for the detailed response!