How to "avoid request assertions" ?

[francoisbillet]

Hi there,

My team and I have been using MSW for a few months and we think it's great.
However, there's an issue that comes up regularly.

How to avoid request assertions, as the doc's best practices suggest, and test what the application does since every HTTP request is mocked ?

.

1/ Testing that a list of products is correctly displayed:

If I want to test that my list of products display every product title and price, it is easy since it's a simple GET request with no path param and no body :

.

2/ Testing that a product gets updated:

This is where I think it gets trickier.
I want to test that when I change a product's title through a form, the new title is displayed (instead of the old one). Ideally, I'd assert that the new title is present in the document (i.e not testing implementation details, but what the user actually sees). But since the list of products is fetched from an API, it is mocked.

• We are currently handling it like this :
  

We have a boolean flag that we set to true if the update of the product is called with the proper params and body. This is testing implementation details, which is not great, but at least it verifies that the back-end is called with the right information.

• This is the other option we have, that would come down to mocking differently the second request to GET products and return the updated product :

Here, we check that the UPDATE is called with the expected information AND we mock differently the new call to GET products. We assert that the title of the product was updated. Of course it was updated since I explicitly indicated that the second GET products should return the updated product !

What's the best way to handle this ?

Thanks in advance,
Funky_Creep

[kettanaito]

Hi, @francoisbillet. Thanks for raising this, I will use this thread for reference since I heard about a similar confusion in the past.

How to avoid request assertions

The best practice in the docs is meant to be a safe default. Most teams and most tests must focus on testing the UI, asserting what happens in the realm observable by the user. There are exceptions to this, and the page mentions those too! Not all requests will find reflection in the UI. Some won't. For those, it's okay to assert on the request itself.

We have a boolean flag that we set to true if the update of the product is called with the proper params and body.

Drop this state and instead return a mocked 400 response if the request payload is incorrect. Behave as a server. This will allow you to drop any assertions around your internal state and instead assert on the successful state of the UI. Because if the request payload is invalid, your component will receive a 400 response instead of a 200/201 response it expects.

Let's talk about mocking mutations in general. One thing a lot of folks miss out on is that an API mock is your boundary. For example, on a typical GET+POST+GET test scenario, you don't have to create an initial set of data, then update it, then make sure the updated version is displayed. That's fine to do in an E2E test, but we are talking about integration tests here.

For integration tests, you check two things:

1. My component renders whichever list of data the mock returns.
2. My component submits the edit form with the right data (here's where asserting on the request payload may be okay, too).

The update flow is tangentially covered within these two test cases. Then, you do a proper user flow that includes mock data and actual updates in an E2E test to complete the picture.

Does this make sense?

[francoisbillet]

Hi, @kettanaito
Thank you for your answer and your work on MSW !

Drop this state and instead return a mocked 400 response if the request payload is incorrect. Behave as a server.

Oh yes this is great ! I'll test that shortly.

Then, you do a proper user flow that includes mock data and actual updates in an E2E test to complete the picture.

We're not currently doing E2E tests in our team. At one point we were but it was time-consuming (use of another external tool) and complicated because of authentication with google suite. We didn't think it was worth the effort, and we thought we could cover most of the E2E use cases with integration tests anyway.

Do you recommend any tool regarding E2E testing ?

[kettanaito]

Do you recommend any tool regarding E2E testing ?

Look into Playwright and its Authentication recommendations. You can basically save any session (cookies) and apply them in any test. That makes auth-based tests fast and more straightforward to write.

I encourage you to explore other E2E tools as there are certain things you can only test with a proper E2E test suite, like complete user flows.

[francoisbillet]

I'll check it out.
Thank you and keep on the good work ! =)