userEvent.click triggers warning that it must be wrapped in act
See original GitHub issueIn this sample code, after running tests I get “Warning: An update to Test inside a test was not wrapped in act(…).” I have seen the kentcdodds’ blog and also other sources and as far as I know I have done everything right. Isn’t this a bug of userEvent.click?
Code:
import * as React from 'react';
import {render} from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import {useState} from "react";
import {Button} from '@material-ui/core';
function Test() {
const [result, setResult] = useState(0);
const handle = () => {
new Promise(resolve => {
resolve(1);
}).then((result) => {
setResult(1);
});
};
return (
<>
<Button
className="test-button"
onClick={() => {
handle();
}}
/>
<div>{result}</div>
</>
);
}
test('Test', () => {
render(<Test/>);
userEvent.click(document.querySelector('.test-button'));
});
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (6 by maintainers)
Top Results From Across the Web
userEvent.click triggers warning that it must be wrapped in ...
Warning : An update to Foobar inside a test was not wrapped in act(...). When testing, code that causes React state updates should...
Read more >React Testing Library with userEvent.click wrong act() ...
I was finally able to track down a workaround. This GitHub post mentions wrapping userEvent() calls in act() which I've already done.
Read more >React Testing Library and the “not wrapped in act” Errors
click triggers fetchData to be called, which is an asynchronous call. When its response comes back, setPerson will be invoked, but at this...
Read more >fireEvent...) and act(() => userEvent. ...
You NEVER need to wrap userEvent or fireEvent in act. ... We should warn against the use of act unnecessarily: import {screen, fireEvent, ......
Read more >Fix the "not wrapped in act(...)" warning
When testing, code that causes React state updates should be wrapped into act(...): act(() => { /* fire events that update state ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

After several years of fighting against
act, I have the firm belief thatactis sadly an anti-pattern. It forces tests to know about how rendering happens. Tests need to know whether if there’s auseEffectthat triggers an async rerendering or not. In my book and in many books, that’s called an anti-pattern. The community, perhaps over-trusting community leaders, has been unquestionably sprinkling act and waitFor here and there to silence these warnings.Now that I let that out my system, I can get back to the subject 😺 :
It seems some bugs are fixed in version 14.0.0 and I stop getting act warnings after upgrading.
@babramczyk If the
Appinfailing.test.jsis exactly the component under test in your local setup, I have no explanation why there is an act warning. If it is only a part of the real component under test, look into what you do in theuseEffectbeside triggering the mock function. If youruseEffectcauses a rerender, you’ve got your culprit.