Commits on Sep 26, 2024

1. feat: Add additional auto advance time controls …

   TL;DR This adds a new mode for automatically advancing time that moves
   more quickly than the existing shouldAdvanceTime, which uses real time.
   
   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 is different from the existing `shouldAdvanceTime` in the following
   ways:
   
   `shouldAdvanceTime` is essentially `setInterval(() => clock.tick(ms), ms)` while this feature is `const loop = () => setTimeout(() => clock.nextAsync().then(() => loop()), 0);`
   
   There are two key differences between these two:
   
   1. `shouldAdvanceTime` uses `clock.tick(ms)` so it synchronously runs all timers inside the "ms" of the clock queue. This doesn't allow the microtask queue to empty between the macrotask timers in the clock whereas something like `tickAsync(ms)` (or a loop around `nextAsync`) would. This could arguably be considered a fixable bug in its implementation
   2. `shouldAdvanceTime` uses real time to advance the same amount of real time in the mock clock. The way I understand it, this feels somewhat like "real time with the opportunity to advance more quickly by manually advancing time". This would be quite different: It advances time as quickly possible and as far as necessary. Without manual ticks, `shouldAdvanceTime` would only be capabale of automatically advancing as far as the timeout of the test and take the whole real time of the test timeout. In contrast, `setTickMode({mode: "nextAsync"})` can theoretically advance infinitely far, limited only by processing speed. Somewhat similar to the [--virtual-time-budget](https://developer.chrome.com/docs/chromium/headless#--virtual-time-budget) feature of headless chrome.
   
   In addition to the "quick mode" of `shouldAdvanceTime`, this also adds
   the ability to modify the initially configured values for
   shouldAdvanceTime and advanceTimeDelta.

   

   atscott committed Sep 26, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 8bc8b1d
   • Browse repository at this point

   Copy the full SHA

   8bc8b1d View commit details

   Browse the repository at this point in the history