Can someone help me understand about

delay()

s inside a

runTest{}

? In my mind the delays would wait until I call

advanceTimeBy()

but in practice the test just run and ignore all the delays. What’s the point of the

advanceTimeBy()

then?

any code？

Not necessary, my question was more in the theory part of it. But we can use the code in the readme as example. Take a look here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-test/README.md#controlling-the-virtual-time In this code it’s “controlling” the time, but, if I remove everything after the

launch

block, it still skip the delays and print the numbers instantly. That’s why I’m confused with the use of

advanceTimeBy()

. I see that when you advance the time it changes the

currentTime

variable, but what uses this? I would imagine delays would depend on it but doesn’t seems like the case.

Your understanding is basically correct. The piece you are missing is that

runTest

does some extra stuff after it runs your lambda. It calls

advanceUntilIdle

and checks that all your coroutines actually finish.

delay

does wait, but then it is run during the cleanup phase of

runTest

.

Hmm, so injecting scope idiomatic? As opposed to creating it privately, if UnderTest has a natural lifecycle (destructor)

I recommend it if only for injecting test scopes.

Hm, I always felt dangerous to inject the scope, since then you dont control it, anybody can cancel you

idk that i'd do it for a library API or anything that might be called from Java.

If I create the scope privately, could runTest work at all?

Even inside a library, internal helpers could take the scope controlled privately by the publicly exposed classes.

class Foo(dispatcher: Dispatcher) : Scoped {
	private val scope = SupervisorScope(dispatcher)

	override fun clear() {
		scope.cancel()
	}
}

class Foo(private val scope: CoroutineScope)

I'm mostly talking about this. I could see your point but, Scoped interface predates coroutines in my code, and also has a rxjava implementation (CompositeDisposable) But more over what I fear is that since now scope is injected, its DI responsibility, and there fore I need a singleton CoroutineScope per semantic DI scope, and since scopes are nested I'd need a qualifier

It's invokeOnCompletion

Thanks. So you dont worry about mismatching the scopes?

I actually got tired of DI related bugs and ditched it for awhile 😅 so I haven't run into that issue. Sounds like a question worth a new thread.

Nah, nesting is good, slack: AppScope > WorkspaceScope > ChannelScope etc. Very helpful

@Nick Allen thanks for your reply! So the “secret” is passing the scope so the delay is controlled? If I run the same test you wrote without passing the scope then the delays would not be controller by

advanceTimeBy()

correct?

Right. The test and tested code need to be using the same scope. Sharing the dispatcher allows the test to control the timing of the tested code. Sharing the

Job

allows

runTest

to verify that you aren't leaking coroutines using that scope.

what if I only passin the dispatcher via ctor, as was the norm so far?

Then the CoroutineExceptionHandler that

runTest

installs will not do it job and report uncaught exceptions (JVM on desktop just swallows them iirc)

thats sucks, I dont feel comfortable injecting coroutine scope into my stuff, it might get mismatched with object's DI scope (hence why I created coroutine scope in such objects privately)

@JvmInline value class AppScope(private val scope: CoroutineScope) : CoroutineScope by scope
@JvmInline value class UserScope(private val scope: CoroutineScope) : CoroutineScope by scope

Different types is the easiest workaround I can think of to make mix ups less likely.

well, you can still mismatch the dagger scope annotation with this, i.e. having the Foo be @UserScope and yet injecting yours App(Coroutine)Scope