Receiving 'event was not wrapped in act' warning after upgrading to React 18 #1216

atshakil · 2023-05-23T12:29:59Z

@testing-library/react version: 14.0.0
Testing Framework and version: jest
DOM Environment:

Relevant code or config:

// CompA.tsx

const CompA = () => null;
export default CompA;

// CompB.tsx

import { lazy } from "react";

const CompB = () => {
  const Example = lazy(() => import("./CompA"));

  return <Example />;
};

export default CompB;

// CompC.tsx

import CompB from './CompB';

const CompC = () => <CompB />;

export default CompC;

// CompC.test.tsx

import { render } from "@testing-library/react";
import CompC from './CompC';

// This test will throw `act()` warning even though CompC is not using `lazy` directly.
describe("CompC", () => {
  test(`Renders`, () => {
    expect(() => {
      render(<CompC />);
    }).not.toThrow();
  });
});

What you did:

Run test using yarn test from a CRA configured project.

What happened:

Receiving warning,

console.error
    Warning: A suspended resource finished loading inside a test, but the event was not wrapped in act(...).
    
    When testing, code that resolves suspended data should be wrapped into act(...):
    
    act(() => {
      /* finish loading suspended data */
    });
    /* assert on the output */
    
    This ensures that you're testing the behavior the user would see in the browser. Learn more at https://reactjs.org/link/wrap-tests-with-act

Reproduction:

Sandbox: https://codesandbox.io/p/sandbox/demo-act-warning-nested-1p4vjn?selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A1%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A1%7D%5D&file=%2Fsrc%2FCompC.test.tsx%3A7%2C25

Problem description:

act() warning started to appear after upgrading to React 18.

Wrapping with waitFor approach (as suggested here) has the following drawback.

Considering lazy is used on a shared component, we'll have to update all the tests for all the components that are using the shared component (even though those components are not using lazy directly). For a large codebase, we'll have to update tests for hundreds of components. Even if we have only one shared component using lazy, we'll have to update all the dependent component tests.

Seems like a lot of work!

Could we somehow keep the behavior identical to that on React 16 (act warning is not raised without needing waitFor)? It'll save a lot of developer effort.

Suggested solution:

No warning message

The text was updated successfully, but these errors were encountered:

alone548 · 2023-05-31T06:21:55Z

can i work on this.

alexandrsashin · 2023-05-31T10:43:25Z

@kentcdodds @eps1lon
The problem is in new concurrent rendering in React 18, right?
Do we plan to fix such issue in the next major version?

MatanBobi · 2023-06-01T08:00:24Z

@alexandrsashin The current version of RTL already supports React 18. Having said that, we do have some work that @eps1lon has been working on in our alpha version, @atshakil, can you please upgrade to our alpha version to see if this resolves your issue? :)

Thanks.

atshakil · 2023-06-06T04:53:53Z

@MatanBobi I tested using the PR build from @eps1lon.
And, it works without any warning! Great!

"@testing-library/react": "https://pkg.csb.dev/testing-library/react-testing-library/commit/b156f877/@testing-library/react"

Looking forward to a release soon! :)

alexandrsashin · 2023-06-16T11:22:56Z

@atshakil then you can close such issue.)

MatanBobi · 2023-06-16T20:01:29Z

Let's keep this one open until alpha will be merged to main :)

eps1lon · 2023-06-17T09:12:24Z

Yeah this is one of the scenarios we'd like to address with #1214 but it needs some additional time.

If you're blocked by this, you can always render().unmount() or cleaup() before you exit your test e.g.

+import {cleanup} from '@testing-library/react';

 expect(() => {
   render(<CompC />);
 }).not.toThrow();
+cleanup()

TAGC · 2023-07-25T16:48:30Z

I think I've encountered something similar to this. I've been working on upgrading one of our frontend projects to React 18 and I was a bit stumped seeing thousands of warning messages like the following when running the unit tests after upgrading the React and React Testing Library packages:

console.error
    Warning: An update to Temp 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://reactjs.org/link/wrap-tests-with-act
        at Temp (/Users/.../src/components/Temp/Temp.tsx:5:23)

       6 |   return (
       7 |     <div>
    >  8 |       <button role="button" onClick={() => setFoo(true)}>
         |                                            ^
       9 |         Example
      10 |       </button>
      11 |     </div>

      at printWarning (node_modules/react-dom/cjs/react-dom.development.js:86:30)
      at error (node_modules/react-dom/cjs/react-dom.development.js:60:7)
      at warnIfUpdatesNotWrappedWithActDEV (node_modules/react-dom/cjs/react-dom.development.js:27589:9)
      at scheduleUpdateOnFiber (node_modules/react-dom/cjs/react-dom.development.js:25508:5)
      at setFoo (node_modules/react-dom/cjs/react-dom.development.js:17527:7)
      at onClick (src/components/Temp/Temp.tsx:8:44)
      at HTMLUnknownElement.callCallback (node_modules/react-dom/cjs/react-dom.development.js:4164:14)

 PASS  src/components/Temp/Temp.spec.tsx
  Temp
    ✓ foo (75 ms)

Our company has a very similar frontend project that made the jump to React 18 several months back and doesn't have this issue, so I was puzzled what the difference was.

I've finally been able to narrow it down to what appears to be a regression between v13.4.0 and v14.0.0 of this package - or more specifically, between v13.5.0-alpha.1 (which is okay) and v14.0.0-alpha.1. With v13.5.0-alpha.1 or earlier, the output when running the same test is simply:

 PASS  src/components/Temp/Temp.spec.tsx
  Temp
    ✓ foo (49 ms)

This was the component I was testing:

import { useState } from 'react'

export function Temp() {
  const [_, setFoo] = useState(false)

  return (
    <div>
      <button role="button" onClick={() => setFoo(true)}>
        Example
      </button>
    </div>
  )
}

This was my test case:

import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

import { Temp } from './Temp'

describe('Temp', () => {
  it('foo', async () => {
    render(<Temp />)

    await userEvent.click(screen.getByRole('button', { name: 'Example' }))
  })
})

alexandrsashin · 2023-07-25T19:00:09Z

@TAGC Yes, versions of libraries are important. When I had problems with act(...) warnings I analyzed schema of RTL dependencies and carefully upgraded all of them.
https://twitter.com/AlexandrSashin/status/1670814494119821312/photo/1
It solved my problems.

Your test looks good and you can improve it using userEvent.setup(). As I understood from docs (https://testing-library.com/docs/user-event/setup/) using userEvent.setup() is recommended in v14 and further versions userEvent-library.

pzaczkiewicz-athenahealth · 2023-08-08T20:26:26Z

While searching for this error, I came across #1051 in my search first.

I created a reproduction repo here: https://github.com/pzaczkiewicz-athenahealth/react-datepicker-user-event-test-failure

However, I wasn't able to use https://pkg.csb.dev/testing-library/react-testing-library/commit/b156f877/@testing-library/react successfully. I had issues installing it with yarn add, and even if I downloaded it locally, I'd get a new "There are no accessible roles" error.

pzaczkiewicz-athenahealth · 2023-08-10T18:16:48Z

I'm going to log a separate issue, as my issue happens in the middle of await user.type, not upon unmounting.

michalstrzelecki · 2023-09-04T09:35:44Z

We have stuck on 13.4 because of this issue.

dougludlow · 2023-10-11T16:45:58Z

@TAGC Yes, versions of libraries are important. When I had problems with act(...) warnings I analyzed schema of RTL dependencies and carefully upgraded all of them. twitter.com/AlexandrSashin/status/1670814494119821312/photo/1 It solved my problems.

Your test looks good and you can improve it using userEvent.setup(). As I understood from docs (testing-library.com/docs/user-event/setup) using userEvent.setup() is recommended in v14 and further versions userEvent-library.

Yup, making sure there was only one version of @testing-library/dom fixed it for me. I forgot to upgrade eslint-plugin-jest-dom.

btmnk · 2023-10-26T12:35:09Z

@TAGC Yes, versions of libraries are important. When I had problems with act(...) warnings I analyzed schema of RTL dependencies and carefully upgraded all of them. twitter.com/AlexandrSashin/status/1670814494119821312/photo/1 It solved my problems.
Your test looks good and you can improve it using userEvent.setup(). As I understood from docs (testing-library.com/docs/user-event/setup) using userEvent.setup() is recommended in v14 and further versions userEvent-library.

Yup, making sure there was only one version of @testing-library/dom fixed it for me. I forgot to upgrade eslint-plugin-jest-dom.

Thank you so much! This solved it for me as well.
I didn't realize @testing-library/[email protected] and @testing-library/[email protected] would use different versions of @testing-library/dom so now I just installed it separately and both use the same version now and the warnings are gone..

Should I be using a different user-event version for 14.0.0?

alexandrsashin · 2023-10-28T17:50:01Z

@btmnk if you use the lastest version of RTL I recommend using the latest version of @testing-library/user-event.

btmnk · 2023-10-28T18:06:35Z

@btmnk if you use the lastest version of RTL I recommend using the latest version of @testing-library/user-event.

But the latest version of @testing-library/user-event has a different version of @testing-library/dom than the latest version of @testing-library/react.. So my assumption was that it's intended to use a specific version of user-event to go with @testing-library/react so the dependencies are also in sync.

I'm used to such library versions all being kept in sync but I guess that's not the case here.. (e.g. for every version of @testing-library/react there is also the same version of @testing-library/user-event so the compatibility is clear)

// EDIT:

Hmm I checked the repositories just now and user-event only uses the dom library as a peerDependency. So I assume the problem was the time when I installed each of the two packages. When I first installed @testing-library/react it probably installed a different version of dom than @testing-library/user-event did (since I installed that quite a while later).
Not sure exactly how lockfiles behave in that case but I think they locked a different sub dependency of @testing-library/dom.

So nvm then, it was just an issue on my side. When installing both at the same time they should both use the same version of dom.

alexandrsashin · 2023-10-28T18:28:43Z

Nowadays I think the best solution for any project - upgrade all @testing-library packages + eslint plugins, read migration guides (if it is needed) and check that only one common @testing-library/dom version in package-lock.json or in yarn.lock.

wuarmin · 2024-01-10T10:02:03Z

Hey,
I have this deps installed:

  "devDependencies": {
    "@testing-library/react": "^14.1.2",
    "@testing-library/jest-dom": "^6.2.0",
    "@testing-library/user-event": "^14.5.2",
    "cross-fetch": "^4.0.0",
    "eslint": "^8.56.0",
    "eslint-config-react-app": "^7.0.1",
    "jsdom": "^23.2.0",
    "msw": "^2.0.13",
    "vite-plugin-eslint": "^1.8.1",
    "vitest": "^1.1.3"
  }

I'm using react v18 and here's a test:

it("should create a MOTO paymentxxx", async () => {
  const {
    user,
    getByPlaceholderText,
    getByRole,
  } = setup();

  // search for a customer
  const lastNameInput = getByPlaceholderText("Last Name");
  const firstNameInput = getByPlaceholderText("First Name");

  await user.type(lastNameInput, "Miles"); // this produces the warning
});

function setup() {
  const user = userEvent.setup();
  const utils = render(
      <CreatePayment />
  );
  return {
    ...utils,
    user,
  };
}

As soon as I call user.type, I get as many warnings as the input has letters. In this case "Miles", so 5 identical warnings:

Warning: An update to CustomerSearch 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://reactjs.org/link/wrap-tests-with-act
    at CustomerSearch (/home/node/repo/apps/payments/src/features/customer-search/customer-search.component.jsx:16:29)
    at div
    at CreatePayment (/home/node/repo/apps/payments/src/features/create-payment/create-payment.component.jsx:18:43)
    at QueryClientProvider (file:///home/node/repo/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@tanstack/react-query/build/lib/QueryClientProvider.mjs:41:3)
    at Wrapper (/home/node/repo/apps/payments/src/features/create-payment/tests/create-payments-basic.test.jsx:1190:20)

Please could someone help me how to solve this? The amount of warnings is really annoying.

Thanks!

alexandrsashin · 2024-01-10T10:27:15Z

@wuarmin
I can advice to do such steps:

Check @testing-library/dom version (use npm ls @testing-library/dom or yarn why @testing-library/dom). You need to have only one version of the library.
Use expect(await screen.findBy...).toEqual(...) to check the end of the component setup() (if you send requests before the component mounting).

wuarmin · 2024-01-10T11:07:54Z

@alexandrsashin Thank you!!

  /@testing-library/[email protected]:
    resolution: {integrity: sha512-fB0R+fa3AUqbLHWyxXa2kGVtf1Fe1ZZFr0Zp6AIbIAzXb2mKbEXl+PCQNUOaq5lbTab5tfctfXRNsWXxa2f7Aw==}
    engines: {node: '>=14'}
    dependencies:
      '@babel/code-frame': 7.23.5
      '@babel/runtime': 7.23.6
      '@types/aria-query': 5.0.4
      aria-query: 5.1.3
      chalk: 4.1.2
      dom-accessibility-api: 0.5.16
      lz-string: 1.5.0
      pretty-format: 27.5.1
    dev: true

  /@testing-library/[email protected]:
    resolution: {integrity: sha512-FlS4ZWlp97iiNWig0Muq8p+3rVDjRiYE+YKGbAqXOu9nwJFFOdL00kFpz42M+4huzYi86vAK1sOOfyOG45muIQ==}
    engines: {node: '>=14'}
    dependencies:
      '@babel/code-frame': 7.23.5
      '@babel/runtime': 7.23.8
      '@types/aria-query': 5.0.4
      aria-query: 5.1.3
      chalk: 4.1.2
      dom-accessibility-api: 0.5.16
      lz-string: 1.5.0
      pretty-format: 27.5.1
    dev: true

I really don't know what the reason was, but somehow I had 2 versions of @testing-library/dom (9.3.3 and 9.3.4) in my workspace. @testing-library/dom is a peer dep of @testing-library/user-event and @testing-library/user-event was just installed at the root of my workspace.

I solved the problem as follows:

Add "@testing-library/dom": "^9.3.4" to the app level (package.json)
run pnpm install --filter app-name
Run the tests -> the issue was solved!!!
Remove the "@testing-library/dom": "^9.3.4" from the app level (package.json)
run pnpm install --filter app-name
Run the tests again -> The problem was still solved!!!

I don't understand how the problem was solved. Do you know? I haven't actually changed anything technically, just added the packaged and removed it after that.

The only file that was changed after this procedure was pnpm.lock.yaml. There was now only one entry with version 9.3.4.

Thanks

oncet · 2024-01-12T11:53:37Z

Was having the same error. It turns out it was cuased by @storybook/test installing a different, more newer, version of RTL. Uninstalled since we are not doing testing with Storybook and the error went away.

supuwoerc · 2024-08-11T07:54:11Z

Any progress on this issue?

rriski · 2024-08-12T08:08:23Z

For people struggling with "was not wrapped in act(...)" with fake timers I managed to fix the (thousands of issues) warnings by changing:

userEvent.setup({ advanceTimers: jest.advanceTimersByTime })
⬇️
userEvent.setup({ advanceTimers: jest.advanceTimersByTimeAsync })

We have fake timers enabled globally with (see https://jestjs.io/docs/configuration#faketimers-object):

fakeTimers: {
    enableGlobally: true,
    advanceTimers: true,
}

jest.advanceTimersByTimeAsync was added in jest v29.5.0.

I haven't seen this approach mentioned in any of the issues referencing the act warning errors. Perhaps https://testing-library.com/docs/using-fake-timers/ should be updated to mention this?

Found this blog post helpful in explaining jest.advanceTimersByTimeAsync https://gamliela.com/blog/advanced-testing-with-jest.

atshakil mentioned this issue May 23, 2023

Document "How to test React.lazy" testing-library/testing-library-docs#1255

Closed

atshakil closed this as completed Jun 16, 2023

MatanBobi reopened this Jun 16, 2023

eps1lon linked a pull request Jun 17, 2023 that will close this issue

fix: Require await act(...) #1214

Draft

eps1lon added the bug Something isn't working label Jun 17, 2023

cee-chen mentioned this issue Aug 1, 2023

Add support for React 18 elastic/eui#7012

Merged

15 tasks

pzaczkiewicz-athenahealth mentioned this issue Aug 10, 2023

'event was not wrapped in act' warning with React 18, react-datepicker and user.type #1231

Open

MatanBobi mentioned this issue Aug 22, 2023

Lots of new act warnings since 9.3.1 testing-library/dom-testing-library#1251

Closed

Janpot mentioned this issue Sep 22, 2023

Bump eslint-plugin-react to ^7.33.2 mui/material-ui#38117

Merged

1 task

apvale mentioned this issue Oct 18, 2023

chore: update eslint-plugin-jest-dom Localitos/pluto#1046

Merged

8 tasks

saurabhchatterjee23 mentioned this issue Nov 6, 2023

Add ui/unit tests to BarCodeScanScreen NotificationsScreen NMF-earth/nmf-app#367

Open

MatanBobi mentioned this issue Nov 7, 2023

Warnings of test not wrapped in act since 9.3.2 testing-library/dom-testing-library#1275

Closed

MatanBobi mentioned this issue Jun 6, 2024

[@storybook/test] Move @testing-library/dom to a peerDependency storybookjs/storybook#27532

Open

DiegoAndai mentioned this issue Jun 28, 2024

[mui-utils][test] Remove usages of deprecated react-dom APIs mui/material-ui#42780

Merged

MartynasStrazdas mentioned this issue Sep 4, 2024

[Tree-widget]: learning snippets iTwin/viewer-components-react#1031

Merged

kwasniew mentioned this issue Sep 25, 2024

test: reduce noise from test warnings Unleash/unleash#8251

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Receiving 'event was not wrapped in act' warning after upgrading to React 18 #1216

Receiving 'event was not wrapped in act' warning after upgrading to React 18 #1216

atshakil commented May 23, 2023 •

edited

Loading

alone548 commented May 31, 2023

alexandrsashin commented May 31, 2023

MatanBobi commented Jun 1, 2023 •

edited

Loading

atshakil commented Jun 6, 2023 •

edited

Loading

alexandrsashin commented Jun 16, 2023

MatanBobi commented Jun 16, 2023

eps1lon commented Jun 17, 2023

TAGC commented Jul 25, 2023

alexandrsashin commented Jul 25, 2023

pzaczkiewicz-athenahealth commented Aug 8, 2023 •

edited

Loading

pzaczkiewicz-athenahealth commented Aug 10, 2023

michalstrzelecki commented Sep 4, 2023

dougludlow commented Oct 11, 2023

btmnk commented Oct 26, 2023

alexandrsashin commented Oct 28, 2023

btmnk commented Oct 28, 2023 •

edited

Loading

alexandrsashin commented Oct 28, 2023

wuarmin commented Jan 10, 2024 •

edited

Loading

alexandrsashin commented Jan 10, 2024

wuarmin commented Jan 10, 2024 •

edited

Loading

oncet commented Jan 12, 2024

supuwoerc commented Aug 11, 2024

rriski commented Aug 12, 2024 •

edited

Loading

Receiving 'event was not wrapped in act' warning after upgrading to React 18 #1216

Receiving 'event was not wrapped in act' warning after upgrading to React 18 #1216

Comments

atshakil commented May 23, 2023 • edited Loading

Relevant code or config:

What you did:

What happened:

Reproduction:

Problem description:

Suggested solution:

alone548 commented May 31, 2023

alexandrsashin commented May 31, 2023

MatanBobi commented Jun 1, 2023 • edited Loading

atshakil commented Jun 6, 2023 • edited Loading

alexandrsashin commented Jun 16, 2023

MatanBobi commented Jun 16, 2023

eps1lon commented Jun 17, 2023

TAGC commented Jul 25, 2023

alexandrsashin commented Jul 25, 2023

pzaczkiewicz-athenahealth commented Aug 8, 2023 • edited Loading

pzaczkiewicz-athenahealth commented Aug 10, 2023

michalstrzelecki commented Sep 4, 2023

dougludlow commented Oct 11, 2023

btmnk commented Oct 26, 2023

alexandrsashin commented Oct 28, 2023

btmnk commented Oct 28, 2023 • edited Loading

alexandrsashin commented Oct 28, 2023

wuarmin commented Jan 10, 2024 • edited Loading

alexandrsashin commented Jan 10, 2024

wuarmin commented Jan 10, 2024 • edited Loading

oncet commented Jan 12, 2024

supuwoerc commented Aug 11, 2024

rriski commented Aug 12, 2024 • edited Loading

atshakil commented May 23, 2023 •

edited

Loading

MatanBobi commented Jun 1, 2023 •

edited

Loading

atshakil commented Jun 6, 2023 •

edited

Loading

pzaczkiewicz-athenahealth commented Aug 8, 2023 •

edited

Loading

btmnk commented Oct 28, 2023 •

edited

Loading

wuarmin commented Jan 10, 2024 •

edited

Loading

wuarmin commented Jan 10, 2024 •

edited

Loading

rriski commented Aug 12, 2024 •

edited

Loading