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.
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.
An example of this from coder/coder that motivated the design of Quartz's API: https://github.com/coder/coder/blob/a5e4bf38fec66c5e7ecc96b0...
--- (btw: just read your blog on R -- love it)
Naming is indeed hard.
type NowFunc func() time.Time
func getGreeting(nowFunc NowFunc) string {
now := nowFunc()
if now.Hour() < 12 {
return "Good Morning"
}
return "Good day"
And just pass in `time.Now` in for live code, and your own inline function for simulating a time in tests.
Once you've done that same "make a low-tech simple replacement" for all of sleep, context deadlines, tickers, AfterFuncs, etc all of which are quite commonly used... you've basically done everything these libraries do. At about the same level of complexity.
In which case no, it falls into the same kind of issues that the post is describing as being problematic.
It's quite tricky is sort of the bottom line. It's not enough to just create fake time there's a lot more to it.
Quartz looks quite interesting though. Gonna have to explore it in detail, because I agree with most of their claims in the article. I'm not 100% sold on their solutions being actual solutions and not just "often an improvement", but that'll probably be clear after using it for a bit / reading it in detail.
[0]: https://blog.davidv.dev/posts/cursing-a-process-vdso-for-tim...