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

• @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.

[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?

[ph-fritsche]

1. Some technical information on this issue is outdated. This issue was based on user-event@12.2. In the latest (and currently only supported version) user-event@14 all methods are asynchronous.
2. As demonstrated in the Codesandbox example above, the issue is based on incorrect information and was actually a non-issue to begin with. (Note that Codesandbox was also updated since, you might need to recreate it locally if you want to verify.)
3. user-event should not be wrapped in act. If you get an act warning, your code does something it either shouldn’t or that you are not aware of - like a delayed asynchronous state update.
4. Such an update might be the result of the test in question or a leaking test running earlier.

---

One use case would be to test the separate parts of the UI after a button press. […] I believe the intuitive name implies it should be used for code that needs to be parsed before every test.

An interaction that involves moving parts of the component under test should never be before the test. A failure of this step is a failure of the component under test.

You could also copy & paste code for each test and wait for it to finish, but you could say that for almost any use case for beforeEach

And those cases not covered by “almost” should go into a beforeEach. Rule of thumb: If there’s a symmetrical afterEach/afterAll, the code should go into a before hook. If there isn’t, it is a mistake most of the time.

There is no need to copy&paste code. Write a renderThisPartOfMyApp function and invoke it in the first line of the test. The next dev who has to work with the test might thank you, because they can follow the function name to its declaration and don’t need to jump through code to find beforeEach hooks that might or might not be there.

I’m not clear on why it is bad practice to fire events in before functions and I think people would benefit from an explanation on a highly visited issue like this. […] developer bias

This recommendation is of course biased. There is no technical barrier preventing you from writing you whole test in a beforeEach hook. It’s just that each line in a before hook has the potential to obfuscate a problem or - like this issue demonstrates only too well - to make people look for problems where there is none. That’s why we recommend to avoid this.

---

If you have further questions: Please, let’s keep this issue board tidy and use it for discussing technical details on definite issues. We’ve got a Discussions board with Q&A section and a Discord server for everything else.