Of possible interest to anyone testing concurrent Go code in general and time in particular, a proposed standard library package: https://go.dev/issue/67434
I still don't like that it assumes global monotonic time. It is completely possible for an event to be scheduled in 100ms on one thread and in 200ms in another, and for the latter to run and/or finish first. A time testing system ought to let you test that case, because you're going to hit it in production.
For that you really have no choice but to abandon the time package's API anyhow because you're going to need some way to trigger those things out-of-order.
I've been using this for a while now: https://github.com/thejerf/abtime (my package) and it really lets me get down and dirty with order of operations, when that matters.
I think the purpose of this package is simple - to allow tests to use time.Sleep without having them actually sleep. A lot of things will not be tested with this model - e.g. you can't really test correctness in all traces of events in your concurrent program - but that goal itself is much harder to achieve.
Related: the behavior of time in this proposal was implemented in Go playground more than a decade ago: https://go.dev/blog/playground#faking-time. Unfortunately it was never exposed.
Thanks for sharing this. This is one of the best testing features I've ever seen - I've had so many troubles with timing tests and refactoring around them. I really hope this gets merged.
That looks amazing. Advancing time while things are idle sounds practically perfect, and that's essentially impossible to build as a library. As much as I like the sound of Quartz (the issues they call out are real and very painful and I was getting close to building my own version to solve some), that issue might remove my need for it entirely.
I'm Quartz's primary author, and I hadn't seen this proposal until today.
They are similar in the sense of using a faked clock to make things deterministic. Other than not having to inject the Clock interface, tests using Quartz will probably look fairly similar to this proposal in many cases.
The proposal has a simpler API than Quartz, being able to just run some goroutines and wait until everything is blocked.
However, this brings some limitations on what can be tested, such as time elapsing while computation is occurring (not just elapsing while things are waiting for something else). IMO this is an important limitation, as many interesting time-of-check, time-of-use bugs and edge cases occur because time does elapse during computation in real systems.
