Use clock package in _TimeIntervalStreamSink (and maybe others)

[nightscape]

In order to deterministically test async code, the fakeAsync package currently seems to be the way to go.
Unfortunately, it cannot modify the StopWatch from dart:core, and instead it is recommended to use the clock package which describes itself as

This package provides a Clock class which encapsulates the notion of the "current time" and provides easy access to points relative to the current time. Different Clocks can have a different notion of the current time, and the default top-level clock's notion can be swapped out to reliably test timing-dependent code.

Would it be possible to use this package in _TimeIntervalStreamSink and possibly other places, in order to allow deterministic testing using fakeAsync?

I'd be happy to contribute a corresponding PR!

[hoc081098]

Sound reasonable!
I have just opened PR #661. cc @frankpepermans, please take a look at it :))

[nightscape]

@hoc081098 wow, that was quick!!
Thanks a lot ❤️
I'm already trying this out locally, will let you know how it works.

[brianegan]

As a heads up, we intentionally removed fakeAsync tests from this library because it is fundamentally broken for Streams & timers. FakeAsync can only modify the current Zone's async timers, but the Stream library often runs code in the root Zone (outside the control of FakeAsync).

Therefore, I'd be careful with this change, since it might give folks the impression that it's safe to use FakeAsync, but the fundamental issues are still unsolved.

Please see these discussions:

• FakeAsync can't always flush timers properly google/quiver-dart#583
• Sometimes it is impossible to control async work with zones, because some values are tied to root zone dart-lang/sdk#40131

[nightscape]

Oh, very good point! I wasn't aware of this at all.
I skimmed the discussions and the issue seems to be a rather fundamental one,
where it's not clear if the current behaviour will ever be changed.
Not sure what the best approach would be here, kind of a "damned if you do, damned if you don't" situation...

[fzyzcjy]

+1 This is very much needed, but the FakeAsync's problem seems also big...

[fzyzcjy]

However, I see the flutter repo itself uses fake_async a lot. Indeed testWidgets by default uses it. How did they solve the problem?

[MiniSuperDev]

Hello, any update on this?