react-testing-library: The current testing environment is not configured to support act(...) with vitest and React 18

I raised a similar issue at vitest. But they think (and I kind of agree), that it has to be solved in testing-library.

tldr; of my vitest-issue:

• when testing-library/react resolves IS_REACT_ACT_ENVIRONMENT it uses the first existing of self, window and global as global-object, which in may case is self
• react access IS_REACT_ACT_ENVIRONMENT directly, which is probably globalThis or global link.
• in vitest / jsdom, globalThis and self are not the same object.

The fix

I think the fix is to add

if (typeof globalThis !== 'undefined') {
  return globalThis
}

here: https://github.com/testing-library/react-testing-library/blob/c8c93f83228a68a270583c139972e79b1812b7d3/src/act-compat.js#L5-L28.

The workaround

The workaround is define some kind of proxy-property on global this, that will make sure that self and globalThis have the same value of IS_REACT_ACT_ENVIRONMENT the code in setupFile.ts:

Object.defineProperty(globalThis,"IS_REACT_ACT_ENVIRONMENT", {
  get() {
    if (typeof globalThis.self !== 'undefined') {
      return globalThis.self.IS_REACT_ACT_ENVIRONMENT
    }
  },
  set(value) {
    if (typeof globalThis.self !== 'undefined') {
      globalThis.self.IS_REACT_ACT_ENVIRONMENT = value
    }
  }
})

globalThis.IS_REACT_ACT_ENVIRONMENT = true

I don’t know if it helps, but I had the same error without using Vitest Warning: The current testing environment is not configured to support act(...)

And global.IS_REACT_ACT_ENVIRONMENT = true; didn’t work for me

There is an await act(), but the callback is a synchronous function. This leads to some bad “timing”, so that the actual state-change is just after the act() call, but before the waitFor-call that is done inside waitForLogout()

This paragraph right here was a life-saver after two solid days of fighting through a react 18 upgrade.

Apparently, if you put find* calls inside an act, the timing somehow doesn’t work out… it would be reasonable to think “more awaits better” in terms of timing, but for some reason, awaiting an act that awaits things doesn’t work out well.

The results are extremely confusing and spooky - literally your test can pass and then error after they pass!

$ yarn test -- pages/Home
yarn run v1.22.19
warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.
$ jest pages/Home
 PASS  src/pages/Home/index.test.tsx
  ● Console

    console.error
      Warning: The current testing environment is not configured to support act(...)

This particular project is open source, and you can see the commit that fixed my failing tests here - it has several examples of “things that don’t work if you wrap them in act”:

https://github.com/abtion/muffi.net/commit/b70302f1871e2382025d2f6975ec12786dbcf299

Simply removing some of the act wrappers fixes the timing issues.

This should be covered by documentation maybe?

I know you’re just pulling this functionality from react’s own facilities, but their documentation doesn’t cover this - and I suppose maybe their documentation can’t be expected to cover the interplay with facilities provided by react-testing-library?

Not sure. This was extremely confusing and time consuming and seems like something almost everyone would run into at first.

Could it be detected and guarded against, with a better error message to guide people along maybe? 🤔

The workaround doesn’t totally work for me. The initial error The current testing environment is not configured... to support act(...) goes away, but then I get act warnings I wouldn’t have otherwise.

I’ve made a reproduction here: https://github.com/airjp73/vitest-act-reproduction

Worth noting that this also appears to be exclusive to React 18. If you downgrade everything to React 17 (including downgrading this library to v12), the act warnings go away and you also don’t need to override the global anymore.

saved my life ❤️

@binhphan009 You’re welcome, but in fact, a couple of months after I left that comment here, I re-visited my test suites and removed almost all of the act calls.

It turns out I wasn’t properly waiting for my API-dependent components to load (I use react-query and I obviously mock the backend in these tests, but the wait still needed to be handled) so jest timed out because the UI wasn’t ready.

Wrapping user.click in a waitFor and then again in an act is a bad workaround (as @nknapp rightfully points out). btw, the curly braces are ANOTHER bad workaround: they just cause the callback provided to waitFor to NOT return the promise from user.click which slightly alters its behavior in our favor, but it’s just an accident, not a proper solution.

I’m now back to using await user.click(screen.getByRole('button')) totally error-free.

had this error which randomly failed tests. in my case I had code like this (select an option in dropdown):

fireEvent.mouseDown(...);
fireEvent.click(...);

solution:

await waitFor(() => {
    fireEvent.mouseDown(...);
    fireEvent.click(...);
});

I found a workaround that seems to work.

If you manually add

global.IS_REACT_ACT_ENVIRONMENT = true

To the setupFile the warning will go away.

This should of course be handled by React testing library so it’s not a proper fix. But it allows us to use vitest until this issue is resolved 😃

Thanks for creating that MR, @eps1lon. I think the issue I mentioned is indeed fixed with vitest@0.12.6

@stuarthallows I have just spent a couple of hours trying to find out why I also still get some act-warnings. Maybe you have a similar problem.

The following code is wrong, but the error is very hard to see

it("sends no access token after logout", async() => {
    // ...
    await clickLogoutButton();
    await waitForLogout();
    // ...
})

async function clickLogoutButton() {
  await act(() => {
    return screen.getByText("Logout").click();
  });
}

There is an await act(), but the callback is a synchronous function. This leads to some bad “timing”, so that the actual state-change is just after the act() call, but before the waitFor-call that is done inside waitForLogout()

The function clickLogoutButton should be either completely synchronous:

it("sends no access token after logout", async() => {
    // ...
    clickLogoutButton();  // <---- no "await"
    await waitForLogout();
    // ...
})

function clickLogoutButton() {  // <--- no "async"
  act(() => {  // <--- no "await"
    screen.getByText("Logout").click();
  });
}

or completely asynchronous

it("sends no access token after logout", async() => {
    // ...
    await clickLogoutButton(); 
    await waitForLogout();
    // ...
})

async function clickLogoutButton() {
  await act(async () => { // <--- added "async" to callback
    screen.getByText("Logout").click();
  });
}

Update: There are some eslint-rules, for TypeScript, that can detect such errors. I added the rules require-await and @typescript-eslint/await-thenable to my project.

Tbh. I don’t think it’s good practice to put actions like ‘click’ into a ‘waitfor’.

waitFor is for observation. It may end up in multiple clicks if you are not careful.

waitFor should also not be nested in ‘act’.

Those may be pragmatic workarounds, but not proper solutions.

I am writing this for everybody who is new to testing-library, reading this thread and learning from it.

If these problems still occur, it’s probably a bug, in testing-library or vitest.

With React 17 + @TL/react 12 + @TL/user-event 13 I had tests such as this:

it('handles clicks', () => {
  const spy = jest.fn()
  render(<Button onClick={spy}/>)
  userEvent.click(screen.getByRole('button'))
  expect(spy).toBeCalled()
})

Worked just fine. I was proud of not using act even once in the entire project. (btw, note my test is synchronous. async/await was only needed with more complex components)

I’m working on upgrade to React 18 + @TL/react 13 + @TL/user-event 14 👷 Following the recommendation in the docs I switched out of userEvent:

const user = userEvent.setup()
await user.click(screen.getByRole('button')) // ❗️jest throws timeout error

For most (simple) tests, this was fixed by adding waitFor:

await waitFor(() => user.click(screen.getByRole('button')))

However, the more complex components would throw ‘An update to Comp inside a test was not wrapped in act’. Seems weird because I was under the impression the waitFor does that under the hood. Swallowed my pride 😞 and fixed it by adding act:

await act(() => waitFor(() => user.click(screen.getByRole('button')))) // not as pretty as before, but works

Surprisingly in some cases I get ‘The current testing environment is not configured to support act’ (sadly I can’t tell why it warns for certain components but not for others). After hours of trying to fix it I found a solution completely by accident:

await act(() => waitFor(() => { user.click(screen.getByRole('button')) })) // ✅ curly braces!

I hope this is helpful - either to the wonderful maintainers of TL or any user facing the same warning. 🙏

EDIT: I’m aware the callback in waitFor could be either callback: () => (void | Promise<void>). Still wrapping my head around all of this.

UPDATE: Some of my issues were because I useFakeTimers - this was solved by userEvent.setup({advanceTimers: jest.advanceTimersByTime}). I still faced many “testing environment is not configured to support act” warnings (mainly in components that use react-query 🤔) and ended up overriding console.error to ignore them.

FINAL(?) EDIT (2023-02-06): All of the above is one long workaround for an error caused by me not properly waiting for my components to load. Don’t do it. Read my other comment.

Please don’t do this! Read another comment I left below👇

I’m now back to using await user.click(screen.getByRole(‘button’)) totally error-free.

@targumon So what were your findings and how did you resolve it? 😄

thanks @targumon

await act(() => waitFor(() => { user.click(screen.getByRole(‘button’)) })) // ✅ curly braces!

saved my life ❤️

I’m now back to using await user.click(screen.getByRole(‘button’)) totally error-free.

@targumon So what were your findings and how did you resolve it? 😄

@targumon you teased an answer but I am missing code! 😅