Using the wrong 'waitFor' gives a warning about the wrong 'act'

[kirkobyte]

• react-hooks-testing-library version: 5.0.3
• react version: 16.13.1
• react-dom version (if applicable): 16.13.1
• node version: 14.13.1
• npm (or yarn) version: 1.22.4

Relevant code or config:

import {waitFor} from '@testing-library/react';
import {renderHook} from '@testing-library/react-hooks';

it('does a thing', async () => {
  const {result} = renderHook(() => useTestHook());
  await waitFor(() => expect(result.something).toBe(true));
});

What you did:

Used the wrong version of waitFor

What happened:

The console gave a warning for using the wrong version of act.

Problem description:

While it is true that the wrong version of act is used, it is only used inside of the waitFor here. Which can make it difficult to see where the wrong version of act is coming from.

Suggested solution:

An ESLint rule to check and warn on usage of the wrong waitFor in the same test block?
It seems that the current warning comes from React/React-DOM. Would it be possible to add another warning here on in react-testing-library's waitFor to provide more information?

[joshuaellis]

It seems that the current warning comes from React/React-DOM. Would it be possible to add another warning here on in react-testing-library's waitFor to provide more information?

Firstly, the act that you get from the renderhook return can either be from react-dom or react-test-renderer depending on what test renderer you have installed in your deps. So I guess you'd want an eslint rule to make sure you're getting the waitFor etc. from the render-hooks suite in a block where you're using render-hook?

I'm personally not well versed in creating custom eslint rules. So I'm not sure how that would work tbh. But I'm definitely interested if this is something you want to work on?

How do you think it would work for the user? Would we need a separate package like eslint-plugin-react-hooks vs eslint-plugin-react? or would it be included in the library?

[kirkobyte]

Thanks for the quick response!

We don't have react-test-renderer installed, so I'm assuming in our case it would be from react-dom.

I'm not entirely sure that a custom ESLint rule would be the best solution. But if it is, maybe it could go into eslint-plugin-testing-library? They seem to have some react specific rules there.

Alternatively, is there any way we could detect from within waitFor whether the correct one is being used?

[mpeyper]

Can you run npm ls react-test-renderer and npm ls react-dom and share the results? If everything is react-dom you shouldn't be seeing that error. Using the wrong waitFor could still be problematic, but not because of act.

[kirkobyte]

Sure thing :)

npm ls react-test-renderer
<project-name>@1.0.0 <project-directory>
└── (empty)

<project-name>@1.0.0 <project-directory>
└── react-dom@16.13.1 

[mpeyper]

I just tried setting up a project (bootstrapped with CRA) with the same versions and a stubbed out useTestHook that would allow the test to pass and I cannot replicate the error, although I am getting a different one that the assertion is failing. This is because result.something doesn't exist. Changing it to result.current.something allows the test to pass.

Would you mind sharing the yarn list (I think you're using yarn, right?) output for a few more deps for me?

❯ yarn list react react-dom react-test-renderer @testing-library/react @testing-library/react-hooks
yarn list v1.22.10
warning Filtering by arguments is deprecated. Please use the pattern option instead.
├─ @testing-library/react-hooks@5.0.3
├─ @testing-library/react@11.2.5
├─ react-dom@16.13.1
└─ react@16.13.1
✨  Done in 0.68s.

[mpeyper]

Closing this now. Happy to reopen if there is more info or conversation to be had.

[kapral18]

when using waitFor from testing-library/react while using act from testing-library-react-hooks I get the same error. It goes away if I use waitFor from return of renderHook