Test hangs waiting for promise to resolve

[slauzinho]

Describe the bug

Using the new vi.setSystemTime I added vi.useFakeTimers(); but this seems to be breaking my async tests.
The tests now wait for the promise to resolve, and since we are using fake timers it never happens.

I saw an example that uses await flushPromises() but this doesn't seem to do the trick.

Reproduction

https://stackblitz.com/edit/github-u4au2p?file=src/stores/counter.js

Run yarn test and see the test hang

System Info

System:
    OS: macOS 10.15.6
    CPU: x64 Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
    Memory: 204.80 MB / 32.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 16.6.1 - ~/.nvm/versions/node/v16.6.1/bin/node
    Yarn: 1.22.5 - ~/.yarn/bin/yarn
    npm: 8.3.0 - ~/.nvm/versions/node/v16.6.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  npmPackages:
    vite: ^2.7.12 => 2.7.13 
    vitest: ^0.2.1 => 0.2.1

Used Package Manager

yarn

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[Demivan]

Problem is caused by your usage of setImmediate to resolve the promise. To advance timers and run setImmediate you can run vi.runAllTimers and it works fine:
https://stackblitz.com/edit/github-u4au2p-5duhjr?file=src%2Fstores%2Fcounter.js

[slauzinho]

What's the approach when using a real api call?

https://stackblitz.com/edit/github-u4au2p-urgmzt?file=src/stores/counter.js

[sheremet-va]

What's the approach when using a real api call?

https://stackblitz.com/edit/github-u4au2p-urgmzt?file=src/stores/counter.js

You can follow guide from the docs or use any kind of mocking library to mock fetch call, for example vi-fetch or jest-fetch-mock. Or you can mannually mock it:

globalThis.fetch = vi.fn().mockReturnValue(data)

[slauzinho]

Yeah I know I can mock fetch or library but I'm actually using MSW to avoid having to mock all my requests.

[sheremet-va]

Yeah I know I can mock fetch or library but I'm actually using MSW to avoid having to mock all my requests.

That is what our guide recommends.

[slauzinho]

Yeah and MSW works fine with vitest. The issue is when I have to use useFakeTimers due to the new setSystemTime API released in 0.2.1.

With Jest I could just do:

jest.useFakeTimers('modern').setSystemTime(nee Date('2020-01-01'))

and it didn't hang.

If I understood correctly by using useFakeTimers I will have to mock the API request because otherwise the promise never resolves?

[sheremet-va]

Yeah and MSW works fine with vitest. The issue is when I have to use useFakeTimers due to the new setSystemTime API released in 0.2.1.

If I understood correctly by using useFakeTimers I will have to mock the API request because otherwise the promise never resolves?

Usually no, It shouldn't, if implementation doesn't have something like await new Promise((resolve) => setTimeout(resolve))

The issue happens only with MSW?

We are using the same API jest uses, so I struggle to see where it came from.

[sheremet-va]

Hanging actually comes from response.json, and not from response itself.

[sheremet-va]

With Jest I could just do:

jest.useFakeTimers('modern').setSystemTime(nee Date('2020-01-01'))

and it didn't hang.

Maybe you were using another package for fetch? Happy-dom uses node-fetch.

Using the new vi.setSystemTime I added vi.useFakeTimers(); but this seems to be breaking my async tests.
The tests now wait for the promise to resolve, and since we are using fake timers it never happens.

This is expected behaviour, unfortunately. I recommend using mockdate package, if you relied on setMockedDate before.

[slauzinho]

Maybe you were using another package for fetch? Happy-dom uses node-fetch.

I'm using Axios

Using the new vi.setSystemTime I added vi.useFakeTimers(); but this seems to be breaking my async tests.
The tests now wait for the promise to resolve, and since we are using fake timers it never happens.

This is expected behaviour, unfortunately. I recommend using mockdate package, if you relied on setMockedDate before.

Thanks I will use mockdate, I actually had it install and was running on another test file without issues.

Thank once again for your help 👍

[Demivan]

@sheremet-va would it be a good idea to bring back setMockedDate for current date mocking? I feel like fake-timers would be an overkill for most users.

[sheremet-va]

I do agree it's an overkill, but don't like having two methods for this.

We can use mockdate if timers aren't mocked in setSytemTime and reset it inside useRealTimers

[Demivan]

We can use mockdate if timers aren't mocked in setSytemTime and reset it inside useRealTimers

That is a great idea.