`TestClock` feels like it should have `plusAssign`...

# stdlib

[jw]

TestClock feels like it should have `plusAssign`/`minusAssign` of a Duration as a convenience. clock += 2.minutes

[jw]

Implementation would basically be reading += amount.toLong(durationUnit)

[jw]

Right now its API relies on you remembering the original duration. I can't write a shared helper method which interacts with a TestClock without also passing in a DurationUnit. Otherwise someone might create an instance that ticks in seconds whereas i'm trying to test for millisecond behavior

[ilya.gorbunov]

Seems reasonable, noted that.

[jw]

I was going to suggest durationUnit being a public val on TestClock to avoid the not knowing what units you're in, but now I'm wondering whether both values should be entirely implementation detail.

[jw]

Of course by doing so there's a potential to overflow the value in whatever is the default unit. You could fix this by dynamically scaling the unit and only moving down in precision when you're about to overflow. But that doesn't play well with marks which were already captured.

So maybe you just still pass a unit as measurement granularity but otherwise the Long is entirely implementation detail and you only interact with plusAssign/minusAssign Duration

[jw]

and possibly a computed val to expose the current "time"? now it sounds like I'm reinventing what's already there...

I think I'm back to making durationUnit a public val in TestClock simple smile (with plusAssign/minusAssign for convenience still)

[ilya.gorbunov]

We're going to provide only plusAssign operator in TestClock and hide its other implementation details (reading and unit).