userEvent.click triggers warning that it must be wrapped in act in beforeEach

[amandapouget]

• @testing-library/user-event version: 12.2.2

• Testing Framework and version: Jest 26.6.3
• DOM Environment: whatever default ships with Jest 26.6.3

Relevant code or config

    beforeEach(() => {
        userEvent.click(button.getByTestId('foobar'));
    });

What you did:
Ran the test

What happened:

Warning: An update to Foobar inside a test was not wrapped in act(...).
    
    When testing, code that causes React state updates should be wrapped into act(...):
    
    act(() => {
      /* fire events that update state */
    });
    /* assert on the output */
    
    This ensures that you're testing the behavior the user would see in the browser. Learn more at https://fb.me/react-wrap-tests-with-act
        in Foobar

Reproduction repository:

Problem description:
We don't have this problem when clicking the same button inside the test itself. But in beforeEach, it flips out and demands that we wrap in act and await. Then the warning goes away.

Suggested solution:
Either fix it or document it in the description for userEvent.click.

[kentcdodds]

Hi @amandapouget,

We don't have this problem when clicking the same button inside the test itself. But in beforeEach, it flips out and demands that we wrap in act and await.

Here's a blog post to explain what that warning is all about: https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning

And here's another blog post to suggest you change the structure of your test to avoid issues like this: https://kentcdodds.com/blog/avoid-nesting-when-youre-testing

This may help as well: https://kentcdodds.com/blog/write-fewer-longer-tests

The recommendation is to restructure your test and not do stuff like this in those setup/teardown hooks (like beforeEach and afterEach). Good luck!

[amandapouget]

Can you update the documentation for userEvent.click to say either:
a) do not use in beforeEach, or
b) you must wrap in act when using in beforeEach

Right now the docs say that the only time you need to wrap it is when you are using delay, and this example shows that is simply not true.

[kentcdodds]

You're more than welcome to make a PR for recommendation a.

Right now the docs say that the only time you need to wrap it is when you are using delay, and this example shows that is simply not true.

This is incorrect. userEvent.click is already wrapped in act. The reason the warning is going away fro you isn't because of act but because of async/await. If you read the blog posts I provided hopefully they will explain why.

[amandapouget]

I am reading through them but struggling to find the relevant line of code that explains the functional difference.

When I do:

it('something, () => {
   userEvent.click(<anything>)
});

I do not get a warning. But if move that same line into a beforeEach, I do.

[amandapouget]

So it sounds like I need to open a PR that says, "You do not need to await userEvent.click unless a) you are using delay or b) you are using it in before/after blocks".

Correct?

[kentcdodds]

The recommendation should be to not use this in before/after blocks at all and you only ever need to use await when using type with a delay. And you never need to use act because all the utilities are already wrapped in act.

[amandapouget]

Whether or not to use before/after blocks is a stylistic choice.

Users do not expect there to be a functional difference between putting something in beforeEach and duplicating the same line in every it statement.

Your posts make a compelling stylistic case for "never use before/after" in general, but there's nothing I see in these posts that claims there is a functional difference.

Yet, there seems to be some functional difference with userEvent.click since you have to await it in before/after but do not in it.

I plan to open a PR that says, "Stylistically, we do not believe in using before/after blocks. See [blog posts about stylistic reasons]. Functionally, if you do choose to use a before/after block, you must await userEvent.click to avoid warning messages."

[kentcdodds]

Whether or not to use before/after blocks is a stylistic choice. Users do not expect there to be a functional difference...

This is also incorrect. As your example demonstrates it makes a semantic difference.

You can feel free to open a PR like that, but it will not be merged if it doesn't communicate our intended recommendation.

[amandapouget]

Feel free to change the language of the PR as needed.

[amandapouget]

Yes, my example does illustrate there is some kind of functional difference.

I didn't see anything in your blog posts that highlighted the functional difference that is relevant to the behavior in this case. So I still don't get why, even after reading all three posts.

If you can point me to where in the blog post, you talk about that functional difference, I will more clearly reference or summarize that difference in the PR.

[kentcdodds]

I'm afraid that I don't have any more time to explain it now, but if you'd like to come to my office hours sometime I could walk you through it then :)

[amandapouget]

Sure, sounds good.
I read the post again and still didn't see anything there that explains the difference for this case.

I'll come to office hours and then maybe we can add a sentence of explanation to either the blog post, the README, or this issue. So it won't just say "don't use because style", it says "don't use because functional reason".

That way a future dev has a fighting chance at discovering the why and you don't have to explain it to anyone else. :-)

[ph-fritsche]

While I don't see good reason to use userEvent inside of beforeEach, it certainly is possible and does not require some extra act per se:
https://codesandbox.io/s/quiet-fast-clsk9?file=/src/App.test.js

I guess your test setup - if performed in specific order - covers up some delayed state change.
You might want to examine what exactly makes your code run synchronously / in specific order in one case and asynchronously in the other. Maybe a mocked window.setTimeout?