react-native-testing-library: Using Jest mock timers and waitFor together causes tests to timeout
Describe the bug
Related to #391. Using jest.useFakeTimers()
in combination with waitFor
, causes the tests using waitFor
to fail due to timeout error:
Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.
Relying upon jest.useFakeTimers("modern")
instead causes the above failure for all tests if the file merely imports waitFor
at all, regardless if the given test uses waitFor
or not.
Expected behavior
All tests in the reproduction test case should pass.
Steps to Reproduce
- Clone the reproduction test case.
yarn install
yarn test
Versions
npmPackages:
@testing-library/react-native: ^7.0.1 => 7.0.1
react: ^16.13.1 => 16.13.1
react-native: ^0.63.2 => 0.63.2
react-test-renderer: ^16.13.1 => 16.13.1
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 16
- Comments: 16 (16 by maintainers)
Not sure if I understood your issues correctly. AFAIK when using fake timers you should not use call
waitFor
withawait
.Please compare how were are using fake timers with
waitFor
in our own test suit.It seems that just this change (
await waitFor(() => {
->waitFor(() => {
) fixes yourlegacy-timers.test.js
.Not sure how to fix your failing tests using modern timers.
Okay it looks like the general approach followed by wait-for-expect to capture the global timer funcs before they get mocked works, but it has highlighted a problem with the ‘modern’ timer mocks which is caused partially by the
'react-native'
preset polyfillingglobal.promise
and partially by the new timer mocks mockingprocess.nextTick
. I’ve written most of the code for the first bit but to make it work with modern timers we need to patch a line in ‘@jest/fake-timers’.Will send a PR tomorrow.
Then find “cacheDirectory” and you’ll see the transformed output.
We may adjust our Babel config for testing to reflect that, PRs welcome 😃
@thymikee makes sense. However, given that this library is intended to be used with a JSC/Hermes app, I would think testing in that environment would be ideal for this library.
I’ll try to research further. I’m not sure how I’d go about comparing the compiled output Jest holds in-memory. If you have any guidance on that, it’d be appreciated. Thanks.