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

@stuarthallows

"@testing-library/jest-dom": "5.16.4",
"@testing-library/react": "13.1.1",
DOM Environment: jsdom or happy-dom (happens with both)

Problem description:

After upgrading to @testing-library/react@13.x and react@18.x with vitest. A lot of react tests throw the following warning:

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

I noticed this after switching from jest to vitest, and not changing anything else. (The tests do not show this warning when using jest, but they they show it when using vitest in the same project).

I previously had an unrelated issue causing the same warning with Jest: #1057

I resolved that, by removing a bad implementation of act(). However this time the tests are identical, and works with 1 test-runner and not with another.

Reproduction:

Credit to @stuarthallows for creating a repo that reproduces the problem: https://github.com/stuarthallows/vitest-error

@stuarthallows and @dar5hak also both seem to be having the same problem as me (see my other issue here: #1057 for more details).

Additional information.

In my case, this is breaking unit tests completely because it logs thousands of these warnings and it just stops after around 10 tests are completed.

For me a lot of the errors start with rc-motion

Warning: The current testing environment is not configured to support act(...)
    at Align (/Users/marklyck/colony/colony-frontend/node_modules/.pnpm/rc-align@4.0.12_ef5jwxihqo6n7gxfmzogljlgcm/node_modules/rc-align/lib/Align.js:45:23)
    at DomWrapper (/Users/marklyck/colony/colony-frontend/node_modules/.pnpm/rc-motion@2.5.1_ef5jwxihqo6n7gxfmzogljlgcm/node_modules/rc-motion/lib/DomWrapper.js:28:34)
    at /Users/marklyck/colony/colony-frontend/node_modules/.pnpm/rc-motion@2.5.1_ef5jwxihqo6n7gxfmzogljlgcm/node_modules/rc-motion/lib/CSSMotion.js:57:32

Which is probably running an animation with antd components. But I'm 99% sure that's a red-herring since the same tests and components work just fine with jest. (or testing-library/react@12 and react@17)

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 :)

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.

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:

react-testing-library/src/act-compat.js

Lines 5 to 28 in c8c93f8

    
           function getGlobalThis() { 
        
             /* istanbul ignore else */ 
        
             if (typeof self !== 'undefined') { 
        
               return self 
        
             } 
        
             /* istanbul ignore next */ 
        
             if (typeof window !== 'undefined') { 
        
               return window 
        
             } 
        
             /* istanbul ignore next */ 
        
             if (typeof global !== 'undefined') { 
        
               return global 
        
             } 
        
             /* istanbul ignore next */ 
        
             throw new Error('unable to locate global object') 
        
           } 
        
           function setIsReactActEnvironment(isReactActEnvironment) { 
        
             getGlobalThis().IS_REACT_ACT_ENVIRONMENT = isReactActEnvironment 
        
           } 
        
           function getIsReactActEnvironment() { 
        
             return getGlobalThis().IS_REACT_ACT_ENVIRONMENT 
        
           }

.

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

We're waiting on confirmation for vitest-dev/vitest#1146 (comment). We're matching the globalThis polyfill so it isn't obvious that we can or should change something.

shouldn't a polyfill only apply if the feature itself is not available? I would argue that if globalThis exists, you should use
it, and not the polyfill.

shouldn't a polyfill only apply if the feature itself is not available? I would argue that if globalThis exists, you should use it, and not the polyfill.

We can do that. The code shouldn't necessarily be considered a polyfill. It worked perfectly well when globalThis didn't exist. So there's definitely something wrong in vitest environments since they wouldn't support legacy code that works in any other environment.

We can still fix it by using globalThis if it exists. So feel free to send a PR. But older versions will continue to not work in vitest until they fix that issue on their side as well.

I haven't had a chance to test myself, but I believe this was fixed on vitest's end.

Yes can confirm that this issue is fixed for me with newest vitest version.

@nknapp

I've upgraded to the latest version of vitest (0.12.6 at the time of writing) and it still doesn't resolve the issue. Using the workaround @nknapp here does successfully get rid of the warnings

Also not fixed for me with vitest 0.12.6, Nor does the workaround prevent the warnings.

@eps1lon

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.

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":

abtion/muffi.net@b70302f

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

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👇

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.

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

@binhphan009

saved my life <3

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

@targumon

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

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(...);
});

@targumon

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! 😅

afterAll(() => {
console.error = originalError;
});

For those of you wondering changing the following

describe("something", () => {
  it('should expand all options', async () => {
    render(
      <ProviderWrapper>
        <ProjectsOverview />
      </ProviderWrapper>,
    );

    const expandOptionsButton = screen.getByText('Visuals.table.actions.project.expandOptions').closest('button');
    if (!expandOptionsButton) throw new Error('Expand options Button not found');
    

    await act(async () => {
      await userEvent.click(expandOptionsButton);
    });

    expect(screen.getByText('Visuals.table.actions.option.collapseAll')).toBeInTheDocument();

    expect(screen.getByText('Wii')).toBeInTheDocument();
    expect(screen.getByText('Visuals.addReview')).toBeInTheDocument();
  });
})

To this:

describe("something", () => {
    it('should expand all options', async () => {
    render(
      <ProviderWrapper>
        <ProjectsOverview />
      </ProviderWrapper>,
    );

    const expandOptionsButton = screen.getByText('Visuals.table.actions.project.expandOptions').closest('button');
    if (!expandOptionsButton) throw new Error('Expand options Button not found');

    await userEvent.click(expandOptionsButton);

    expect(screen.getByText('Visuals.table.actions.option.collapseAll')).toBeInTheDocument();

    expect(screen.getByText('Wii')).toBeInTheDocument();
    expect(screen.getByText('Visuals.addReview')).toBeInTheDocument();
  });
})

Fixed my issue. A.K.A. remove the act entirely and just await the userEvent.click instead.

@Danielvandervelden

@Danielvandervelden works indeed, dear legend. Tho the reason why this happens is nicely explained here, for those who have enough time to read through it: https://stackoverflow.com/questions/75448819/async-thunks-cause-warnings-in-tests-wrapped-in-act e.g https://codilime.com/blog/why-should-you-be-grateful-for-act-warnings-in-react-tests/

Hey guys! Idk if someone's still having problem with it, but await waitFor(async () => {}) resolved the warning to me.

Also seeing this issue on jest. None of the workarounds have worked consistently

Fix intermittent React act() failures with proper setup file

FYI for anyone using Jest with Ant Design (antd) or other rc-component libraries, I managed to get Copilot to eliminate these warnings. This was its analysis:

The issue is that rc-components schedules microtasks that fire state updates after the testing library's act() wrapper restores IS_REACT_ACT_ENVIRONMENT to its previous value. Simply setting globalThis.IS_REACT_ACT_ENVIRONMENT = true in setup files doesn't work because Jest runs modules in a sandboxed VM context where Node's globalThis isn't visible to react-dom.

The fix is to use Jest's sandboxInjectedGlobals config option:
// jest.config.js
module.exports = {
  globals: { IS_REACT_ACT_ENVIRONMENT: true },
  sandboxInjectedGlobals: ['IS_REACT_ACT_ENVIRONMENT'],
  testEnvironment: 'jsdom',
};
You need both options. The globals option sets the value, and sandboxInjectedGlobals makes it visible to modules like react-dom running in Jest's sandbox.

Navigation Menu

Repository navigation

The current testing environment is not configured to support act(...) with vitest and React 18 #1061

Problem description:

Reproduction:

Additional information.

tldr; of my vitest-issue:

The fix

The workaround

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

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	function getGlobalThis() {
	/* istanbul ignore else */
	if (typeof self !== 'undefined') {
	return self
	}
	/* istanbul ignore next */
	if (typeof window !== 'undefined') {
	return window
	}
	/* istanbul ignore next */
	if (typeof global !== 'undefined') {
	return global
	}
	/* istanbul ignore next */
	throw new Error('unable to locate global object')
	}

	function setIsReactActEnvironment(isReactActEnvironment) {
	getGlobalThis().IS_REACT_ACT_ENVIRONMENT = isReactActEnvironment
	}

	function getIsReactActEnvironment() {
	return getGlobalThis().IS_REACT_ACT_ENVIRONMENT
	}

The current testing environment is not configured to support act(...) with vitest and React 18 #1061

Description

Problem description:

Reproduction:

Additional information.

Activity

MarkLyck commented on May 4, 2022

airjp73 commented on May 5, 2022

nknapp commented on May 6, 2022

tldr; of my vitest-issue:

The fix

The workaround

eps1lon commented on May 7, 2022

nknapp commented on May 13, 2022

eps1lon commented on May 13, 2022

airjp73 commented on May 13, 2022

ulrichstark commented on May 13, 2022

WonderPanda commented on May 13, 2022

stuarthallows commented on May 14, 2022

nknapp commented on May 28, 2022

mindplay-dk commented on Aug 10, 2022

targumon commented on Sep 6, 2022

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

2 remaining items

nknapp commented on Feb 3, 2023

IanTorquato commented on Feb 3, 2023

targumon commented on Feb 6, 2023

sag1v commented on Jul 5, 2023

nikolyachikm commented on Sep 14, 2023

KimSchneider commented on Oct 5, 2023

Rita0156 commented on May 22, 2024

Danielvandervelden commented on Jun 13, 2024

MichalGorskiOnegini commented on Jun 26, 2024

Lux-Sales commented on Sep 19, 2024

william-will-angi commented on May 24, 2025

jakeboone02 commented on Feb 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions