Is it possible to get notified when the virtual time changes in

runTest

? The standard way of integrating other systems with delay skipping is to inject them a

Clock

that reads from the virtual time. However, sometimes there are systems that cannot be injected a clock in this way, but expose an API method like

foo.setTime(…)

. It would be great if there was a way to register a callback that would be invoked each time the virtual time changes, to notify those services.

Is it possible to get notified when the virtual time changes in

runTest

?

It's not, and I don't think anyone asked for this before. If you're fully confident in your use case, please file an issue on Github; if not, we can discuss it here and maybe arrive at a solution that doesn't need such notifications.

If you have another idea of how to do it, I'm interested. I haven't managed to come up with one. The constraints are as follows: • The other system is a dependency of the SUT. At a very high level, it can be considered to be some sort of task scheduling system. • We cannot modify that system. • That system cannot be injected a

Clock

, and has no otherwise option to "ask what the current time is". • That system can be forced to accept a different current time than the real one. • We could mock it, but that would mean writing non-coroutine-based tests to ensure its correctness, and the coroutines virtual time is the best tool we have to reproduce complex timing issues, so we'd much rather use that if possible. Essentially, it's a system that can be pushed time events to, instead of the usually recommended approach of having a system that pulls time events (through the

Clock

or

TimeSource

).

Are you able to read time from this other system like you would a normal clock? If so, can you can just wrap this other thing with a custom implementation of

Clock

The idea is to go the other way: control

ThirdParty

automatically via normal calls to

delay

.

Right. I'm wondering if a layer of custom abstraction from the third party dep will help. In this case that would be a custom impl of Clock

Is there a known scheduling granularity to this third-party system? If it's large enough, maybe something like this would do the trick:

backgroundScope.launch {
  while (true) {
    delay(50.milliseconds)
    thirdParty.advanceTime(50.milliseconds)
  }
}

If not, does the third-party system provide an interface like "this callback will be run when a new task is scheduled"?

backgroundScope.launch {
  val taskChannel = Channel<suspend () -> Unit>()
  thirdParty.onTaskRegistration { task ->
    taskChannel.trySend {
      delay(task.shouldBeStartedIn)
    }
  }
  for (delayTask in taskChannel) {
    launch {
      delayTask()
      thirdParty.setTime(currentTime)
    }
  }
}

I'm wondering if a layer of custom abstraction from the third party dep will help. In this case that would be a custom impl of Clock

I know this would be better, but we can't modify the third party system.

wouldn't this break

advanceUntilIdle()

Nope, if the only tasks available are the ones in

backgroundScope

,

advanceUntilIdle

will stop.

runTest

's

timeout

argument, etc?

`runTest`'s timeout is in terms of the real time, not virtual time.

> Nope, if the only tasks available are the ones in

backgroundScope

,

advanceUntilIdle

will stop. Oh, that's great to know. I haven't seen this mentioned anywhere in the documentation. > `runTest`'s timeout is in terms of the real time, not virtual time. doesn't your comment here imply the opposite?

I haven't seen this mentioned anywhere in the documentation.

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/-test-scope/background-scope.html

doesn't your comment here imply the opposite?

That's a comment about how

runTest

used to operate, but we changed that since then.

It's a brittle API that's easy to misuse. For example,

I think there was a misunderstanding, this example does not look like what I had in mind. My thinking process was more along the lines of:

runTest {
    registerOnVirtualTimeChange { println("foo") }
    // from now on, each time the virtual time changes, "foo" is printed

    somethingHappens()
    delay(2.minutes)
    somethingElse()
}

The assumption is that the correct usage would be something like

runTest {
    val system = …
    registerOnVirtualTimeChange { system.setTime(currentTime) }

    system.scheduleAt(currentTime + 1.minutes) {
        …
        system.scheduleAt(currentTime + 1.minutes) {
            …
        }
    }

    advanceUntilIdle()
}

But see, here's the issue: the

currentTime

inside the block will only be evaluated when

currentTime

is already 5 seconds. As I said, brittle!

Ah, I understand. Indeed, it's very brittle 😕

Sure. If eventually you understand something new about the problem you're facing or realize that some API from our side would make your job easier, please share your thoughts.

I've thought about it some more, and the fact that

advanceUntilIdle()

etc ignores tasks scheduled in

backgroundScope

does in fact make this entire use-case trivial via the infinite-loop+notify solution.