Exception for [no-wait-for-multiple-assertions] rule

[SevenOutman]

Hi, I'm writing tests for a form component with validation (async). I need to assert two of my form fields show error messages and my assertions went like

await waitFor(() => {
  expect(scree.getByLabelText('Name')).toHaveErrorMessage('Name is required');
  expect(scree.getByLabelText('Company')).toHaveErrorMessage('Company is required');
});

I feel it's totally fine to group these two assertions in a single waitFor block - actually it feels kinda weird to separate them. The inspiration of no-wait-for-multiple-assertions makes perfect sense but does not seem to apply to this use case. And the rule doesn't have an option for customizing behavior. Any suggestions?

[Belco90]

Hi @SevenOutman!

I'm afraid that I don't see how we could add an exception to that.

First, this rule makes sense for your use case too, since when the first error message appears, the second one should be there too, so you only need to await for one of them. This is on the same page as the scenario explained in the Common mistakes with React Testing Library post, so your test fails faster. In general, the waitFor util should look like this in your tests:

1. side-effects triggering async behaviors
2. waitFor for the very first assertion related to the async behavior
3. all the remaining assertions related to the async behavior

I guess your point is about asserting a mock is called once and is called with some args is connected somehow because you are asserting over the very same mock, but asserting a field has an error message, and another field has another error message is not related because they are different elements. But in terms of waitFor and the flow of your component, this is actually connected: both errors will appear after the same async behavior is fulfilled, so you only need to wait for one of them.

Nevertheless, if we find a reason to allow this behavior, I don't think it's doable. How would look like? I can't find a pattern to identify that use case, to be honest.

[SevenOutman]

Hi @Belco90,

Thanks for the answer. But I still find it odd to pick one of those assertions into waitFor. If I'm understanding it correctly, waitFor and following assertions means "waiting for something to happen be cause following assertions depends on it". And multiple error messages at the same time in this case doesn't seem to belong to this category. There's no special one among them that other assertions depends on it.

[Belco90]

I understand your point of view. The same could be argued for the example from Common mistakes with React Testing Library post: Why picking one of the assertions between expect(window.fetch).toHaveBeenCalledWith('foo') and expect(window.fetch).toHaveBeenCalledTimes(1) to be included in the waitFor given call? Why not both?

There's no special one among them that other assertions depends on it.

👆 This sentence from your message is the key. The point is not to wait for only one of them because it's the first one resolving or because it's special, but just waiting for one of them (whichever you prefer) to fail faster, then assert the rest synchronously. Does it feel more natural to wait for all the assertions at once? For sure, but then you don't benefit from failing faster, which is the motivation behind that section of the Common mistakes with React Testing Library post and this rule.

I think in your case, if you don't find any benefit from this rule, you should disable it for that particular test, or even in general if it keeps bothering you. Considering special cases for allowing several assertions would be against the goal of the rule itself, but haven't even found a pattern to identify the use case.

[SevenOutman]

Now I understand. I may probably disable this rule in my project.