feat(jest-fake-timers): Add feature to enable automatically advancing… #15300
Conversation
|
|
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
atscott
force-pushed
the
autoAdvance
branch
2 times, most recently
from
835635d
to
fb18fa9
Compare
|
Is the behaviour of this new method different from the Lines 883 to 889 in bd1c6db |
Good question! Yes, it's quite different, both in correctness and in practicality. I'll update the documentation with some version of this explanation (and please correct me if any of this seems wrong):
There are two key differences between these two:
Given that |
atscott
force-pushed
the
autoAdvance
branch
from
fb18fa9
to
7630c43
Compare
… timers
Testing with mock clocks can often turn into a real struggle when dealing with situations where some work in the test is truly async and other work is captured by the mock clock.
In addition, when using mock clocks, testers are always forced to write tests with intimate knowledge of when the mock clock needs to be ticked. Oftentimes, the purpose of using a mock clock is to speed up the execution time of the test when there are timeouts involved. It is not often a goal to test the exact timeout values. This can cause tests to be riddled with manual advancements of fake time. It ideal for test code to be written in a way that is independent of whether a mock clock is installed or which mock clock library is used. For example:
```
document.getElementById('submit');
// https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
await waitFor(() => expect(mockAPI).toHaveBeenCalledTimes(1))
```
When mock clocks are involved, the above may not be possible if there is some delay involved between the click and the request to the API. Instead, developers would need to manually tick the clock beyond the delay to trigger the API call.
This commit attempts to resolve these issues by adding a feature which allows jest to advance timers automatically with the passage of time, just as clocks do without mocks installed.
atscott
force-pushed
the
autoAdvance
branch
from
7630c43
to
de306d5
Compare
|
Interesting. Do I get it right that this new API is somewhat a variation of
|
Yes, that's right!
I think that's a pretty good idea for an alternative place for this API. Would |
|
The idea I was talking about was to replace |
Ah, you mean that it the automatic/manual would entirely replace the existing |
|
@mrazauskas happy to continue iterating on the API naming. Would you also be able to help with the CI failures? I’m not sure what’s going on there. |
|
Hm.. I think those failures are not related with your code. GHA run all the tests and if they pass, I think all is fine. |
… timers
Summary
Testing with mock clocks can often turn into a real struggle when dealing with situations where some work in the test is truly async and other work is captured by the mock clock.
In addition, when using mock clocks, testers are always forced to write tests with intimate knowledge of when the mock clock needs to be ticked. Oftentimes, the purpose of using a mock clock is to speed up the execution time of the test when there are timeouts involved. It is not often a goal to test the exact timeout values. This can cause tests to be riddled with manual advancements of fake time. It ideal for test code to be written in a way that is independent of whether a mock clock is installed or which mock clock library is used. For example:
When mock clocks are involved, the above may not be possible if there is some delay involved between the click and the request to the API. Instead, developers would need to manually tick the clock beyond the delay to trigger the API call.
This commit attempts to resolve these issues by adding a feature which allows jest to advance timers automatically with the passage of time, just as clocks do without mocks installed.
Test plan
I wrote some unit tests but let me know if you need more.