| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Review requested:
|
Sorry, something went wrong.
|
I don't think Date.now should be passed as a param while enabling timers as it's not a timer. IMHO In this first version Date.now should advance in time when some .tick call happens cc @nodejs/test_runner |
Sorry, something went wrong.
I think it's a timer in the sense that's an API to manipulate or count time in general. But I can see your point too, it can be confusing, I took as an inspiration the last PR and Sinon's fake timers API, this last one also mocks not only the now but the entire Date constructor. But IMO it kinda makes sense to be here, I would expect an API to manipulate date to be in the fake timers implementation as an user.
Regarding this, it's already happening in this implementation, tick is advancing the #now property which is returned by Date.now but setting a time with setTime is not triggering tick, this is a problem that I'll address in the upcoming commits. |
Sorry, something went wrong.
|
Mocking Date.now() without mocking new Date() will be a massive footgun. |
Sorry, something went wrong.
Yeah I thought so later on, it wouldn't make a lot of sense 😄 thanks for clarifying! Will add this to the next steps |
Sorry, something went wrong.
|
a83b9f9 introduces a problem and a question. When runAll is called, the easiest way to implement is to do like @ErickWendel did and tick to Infinity, however, this will break the Date mock as Infinity is not a valid epoch. From here I think we have two options:
Any thoughts? |
Sorry, something went wrong.
| this.#now = 0; | ||
| } else if (this.#isValidDateWithGetTime(args[0])) { | ||
| // First argument is the initial time as Date | ||
| this.#now = args[0].getTime(); |
There was a problem hiding this comment.
do we mean to call .getTime() on the argument, or should this instead be:
| this.#now = args[0].getTime(); | |
| this.#now = DatePrototypeGetTime(args[0]); |
Sorry, something went wrong.
There was a problem hiding this comment.
It's the intended one, if the first argument is an instance of Date then we will call the getTime method on it to get the timestamp
Sorry, something went wrong.
There was a problem hiding this comment.
right but if it's an actual Date object - which may not be instanceof Date - you don't want to rely on the presence of Date.prototype.getTime at runtime.
Sorry, something went wrong.
| #isEnabled = false; | ||
| #currentTimer = 1; | ||
| #now = DateNow(); | ||
| #now = 0; |
There was a problem hiding this comment.
#now should be DateNow unless it's changed by .setTime
Sorry, something went wrong.
There was a problem hiding this comment.
But that differs from the implementation from fake-timers. If the intention is to be close to that API then we wouldn't be able to start it as DateNow, however, I'm not against that too. I think it's worth a discussion with @nodejs/test_runner
On my side I think the pros is that you can start the Date object without actually setting anything on it, as opposed to having to set the time at any given new fake timer instance because otherwise you'd have Jan 1, 1970. Which also can be a pro to some people as it's more explicit to what time is the initial time.
Sorry, something went wrong.
| p.then(common.mustCall((result) => { | ||
| assert.ok(result); | ||
| })); | ||
| p.then( |
There was a problem hiding this comment.
same here
Sorry, something went wrong.
I think runAll shouldn't affect Date.now as it's just releasing all pending operations so option 1 is the best IMHO |
Sorry, something went wrong.
There is a third option here which is to have a property in the enable method which could be called shouldAdvanceTimeOnRunAll that would implement the second option as well. This would cover for use cases where running the timers and checking the date are actually interconnected, for example, testing banking systems that could rely on a timestamp being after another to order events in a timeline after being called from a cron or something |
Sorry, something went wrong.
|
I don't understand the rationale not to progress the clock date whenever it should happen (e.g by 20ms if a 20ms setTimeout delayed has run)? I think this was the sinon/jest behavior and I don't think anyone ever asked for anything different? |
Sorry, something went wrong.
|
I was under the impression that when Date was mocked, time never advanced except manually by the user. |
Sorry, something went wrong.
As far as I remember from our code in fake-timers we always progress Date/performance.now when we progress timers. |
Sorry, something went wrong.
Alright! I think I'll work on them today up to the end and we can implement that version, I also think it's the best solution, then we can have a base v1 ready :) |
Sorry, something went wrong.
|
@ljharb @ErickWendel @benjamingr I think I'm done with this version 😄 if you could please review it 🚀 |
Sorry, something went wrong.
|
Other than my comments LGTM |
Sorry, something went wrong.
|
@khaosdoctor I've retried it one more time, if it fails again I suggest you rebase on top of main. |
Sorry, something went wrong.
|
@RafaelGSS Now it seems to be good to go! |
Sorry, something went wrong.
There was a problem hiding this comment.
Cool!
Sorry, something went wrong.
Commit Queue failed- Loading data for nodejs/node/pull/48638 ✔ Done loading data for nodejs/node/pull/48638 ----------------------------------- PR info ------------------------------------ Title test_runner: Add Date to the supported mock APIs (#48638) Author Lucas Santos (@khaosdoctor) Branch khaosdoctor:test_runner/introduce_improve_fake_timers -> nodejs:main Labels semver-minor, notable-change, author ready, needs-ci, commit-queue-squash, test_runner Commits 3 - test_runner: add Date to the supported mock APIs - Apply suggestions from code review - Apply suggestions from code review Committers 1 - Lucas Santos PR-URL: https://github.com/nodejs/node/pull/48638 Reviewed-By: Benjamin Gruenbaum Reviewed-By: Moshe Atlow Reviewed-By: Erick Wendel Reviewed-By: Rafael Gonzaga ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/48638 Reviewed-By: Benjamin Gruenbaum Reviewed-By: Moshe Atlow Reviewed-By: Erick Wendel Reviewed-By: Rafael Gonzaga -------------------------------------------------------------------------------- ⚠ Commits were pushed since the last approving review: ⚠ - test_runner: add Date to the supported mock APIs ⚠ - Apply suggestions from code review ⚠ - Apply suggestions from code review ℹ This PR was created on Sun, 02 Jul 2023 19:29:31 GMT ✔ Approvals: 4 ✔ - Benjamin Gruenbaum (@benjamingr) (TSC): https://github.com/nodejs/node/pull/48638#pullrequestreview-1655247395 ✔ - Moshe Atlow (@MoLow) (TSC): https://github.com/nodejs/node/pull/48638#pullrequestreview-1630117150 ✔ - Erick Wendel (@erickwendel): https://github.com/nodejs/node/pull/48638#pullrequestreview-1536004400 ✔ - Rafael Gonzaga (@RafaelGSS) (TSC): https://github.com/nodejs/node/pull/48638#pullrequestreview-1665791940 ✔ Last GitHub CI successful ℹ Last Full PR CI on 2023-10-10T12:43:52Z: https://ci.nodejs.org/job/node-test-pull-request/54632/ ⚠ Commits were pushed after the last Full PR CI run: ⚠ - test_runner: add Date to the supported mock APIs ⚠ - Apply suggestions from code review ⚠ - Apply suggestions from code review - Querying data for job/node-test-pull-request/54632/ ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncuhttps://github.com/nodejs/node/actions/runs/6527901651 |
Sorry, something went wrong.
There was a problem hiding this comment.
RSLGTM
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
signed-off-by: Lucas Santos <lhs.santoss@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
|
Merging @anonrig changes in the tests that includes some of them (including the ones failing here) as flaky to check if this will pass |
Sorry, something went wrong.
Sorry, something went wrong.
|
OMG FINALLY ⭐ |
Sorry, something went wrong.
|
Thanks @anonrig for the flaky PRs! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This builds on top of @ErickWendel's #47775, I saw the next steps would be to implement the mock timers for Date.now (and thus, the Date object) and performance.now.
This PR implements the Date.now mock, I'll also work on performance.now on another PR to make it simpler to review. This one includes the Docs already updated and the added tests.
This heavily builds on Sinon's Fake Timers for the base edge cases
To-Do
Next iterations
New MockTimers API
It's also possible to omit the initial parameter and pass on only the initial epoch, which will enable all timers with that epoch set:
Lastly, you can omit all parameters to enable all timers at the epoch 0:
Example usage
All the remaining APIs are the same