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

  1. Clone the reproduction test case.
  2. yarn install
  3. 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)

Most upvoted comments

Not sure if I understood your issues correctly. AFAIK when using fake timers you should not use call waitFor with await.

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 your legacy-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 polyfilling global.promise and partially by the new timer mocks mocking process.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.

jest --showConfig

Then find “cacheDirectory” and you’ll see the transformed output.

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

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.