Async timeout when testing custom hook with jest

[Blond11516]

Describe the bug
I sometimes get a timeout error when I try to run multiple tests on a custom hook which uses React Query and waiting for it to return mocked data.

To Reproduce
I've created a sample repository which reproduces the issue: https://github.com/Blond11516/react-query-test-issue.
The custom hook is https://github.com/Blond11516/react-query-test-issue/blob/main/src/hooks/useUsers.ts and its test is https://github.com/Blond11516/react-query-test-issue/blob/main/src/hooks/__tests__/useUsers.test.ts.

The test setup is as follows:

• I mock my API client to return a blocked promise by default
• I test that the API client is called by the custom hook (works)
• I update my mock to return actual data
• I test that the hook returns the mocked data after calling waitForNextUpdate (or any equivalent variation of waitFor)
• The query never returns the data and the test eventually fails with a timeout

Note that all tests pass if I run them one by one, but the one where data is returned fails as soon as another test is run on the same hook.

Expected behavior
The query should return the data and trigger a hook update.

Desktop

• OS: macOS Catalina 10.15.7
• ReactQuery version: 2.23.1
• React version: 17

Additional context
I've also applied the suggestions I found in other issues related to testing, namely running queryCache.clear() after each test and and awaiting for the query cache not to be fetching to avoid the act warnings, but they didn't fix my issue.

I've actually found three ways of making the tests pass, but they all feel wrong in some way:

1. Wrapping the custom hook in a ReactQueryCacheProvider with a new QueryCache every time. example here
2. Giving each query instance a different key. example here
3. Making the mocked API call return data by default instead of a blocked promise (passes, but requires a call to waitForNextUpdate in every test). example here

These solutions (especially 1 and 2) and the fact that all tests pass independently lead me to believe that the queryCache isn't cleared properly between tests, causing the query to stay cached and not return despite the mock being updated to return a data.

Any help/explanation on this would be greatly appreciated.

[TkDodo]

Not an expert on tests, but aren't describe blocks run in parallel in jest, and only the execution order of it blocks is guaranteed ?

Anyways, I wouldn't rely on test execution order, and a "global" thing like the queryCache, where each test writes to / reads from, is certainly a problem.

I see nothing wrong with wrapping each test in a custom Provider like your solution 1). It will ensure that each test is encapsulated, and I think that's a good thing. It will also allow you to tweak some things for one tests on the query cache, like turning off retries (we discussed that here: #1090 (reply in thread))

[Blond11516]

aren't describe blocks run in parallel in jest, and only the execution order of it blocks is guaranteed ?

Unless I'm not understanding this doc page, everything in a single test file/module is run sequentially (that is, describe blocks are evaluated on module load, but all tests are run in the order they are defined, no matter which describe they're defined in).

I wouldn't rely on test execution order, and a "global" thing like the queryCache, where each test writes to / reads from, is certainly a problem

100% agree with this, which is why I tried clearing the queryCache between each test as suggested here, but for some reason it still didn't work. That said, while working on another testing issue with a colleague I learned that the default queryCache should be frozen when running tests, so I'm gonna have to dig a little deeper into this as this should rule out any query sharing from the equation.

I see nothing wrong with wrapping each test in a custom Provider like your solution 1). It will ensure that each test is encapsulated, and I think that's a good thing.

I also mostly agree on this. This is the solution I ended up going with, but it feels unnecessary and I was hoping to get a better understanding of what was going on in my tests. Again, I'm gonna dig deeper into the whole "default frozen cache" thing next week.

[TkDodo]

describe blocks are evaluated on module load, but all tests are run in the order they are defined, no matter which describe they're defined in

ah yes, you are right. I confused the evaluation of describe blocks with evaluation of tests.

[TkDodo]

This is the solution I ended up going with, but it feels unnecessary

I would argue that resetting the cache after each test feels unnecessary :)

You have a shared mutable resource, and you have to do something when testing this.

If you don’t eliminate the “shared” part, your tests could never run in parallel, which jest would allow via test.concurrent.

[Blond11516]

I would argue that resetting the cache after each test feels unnecessary :)

Actually you're right 😛 I guess I'm mostly confused about why it didn't work. Whether I should be doing it or not is a different story.

[TkDodo]

agreed. would be cool if you'd find it out regardless of that 👍

[Blond11516]

So I haven't had much more time to spend on this, but the one thing I've found is that clearing the query cache in beforeEach instead of afterEach appears to work for some reason. To me both should be the same (except maybe for the first test, but the query cache should be empty by default anyway).

The only thing I can think of right now is that some weird asynchronicity issue prevents the cache from being cleared properly in afterEach, but that's really just a guess.