Do I understand it right, that

advanceUntilIdle

does not "wait" when there is dispatcher switch within a coroutine? For example

delay(100) // skipped
withContext(otherDispatcher){
    delay(100)
}
delay(200) // not called at all on advanceUntilIdle

At least that's what I observed with ktor MockEngine. If this is really the case, it should be mentioned somewhere, because it has cost us hours of debugging.

I think it's mentioned here under Task scheduling: https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/run-test.html

Your sample code doesn't switch dispatchers within a coroutine, it creates another coroutine running on a different dispatcher. Could you provide a bit more details about what you're trying to do?

See also here for my use case: https://kotlinlang.slack.com/archives/C0A974TJ9/p1699377388965069

Do I understand it right, that

advanceUntilIdle

does not "wait" when there is dispatcher switch within a coroutine?

Yes. It is mentioned in every place I can think of.

advanceUntilIdle

,

runCurrent

, etc., all only work with the tasks that the test dispatchers know about. If some other coroutine dispatcher is responsible for the task, there's no way for the test module to know about it and ensure it's completed.

delay(100) // skipped
val waitForResult = launch(otherDispatcher){
    delay(100)
}
delay(200) // not called at all on advanceUntilIdle

I don't know what you mean by this. If this whole block of code executes in a test dispatcher and is followed by

advanceUntilIdle

, then both the first

delay(100)

and

delay(200)

will be skipped.

delay(100)

in the

launch

won't, as it doesn't use virtual time. In this simple case, you don't even need

advanceUntilIdle

, you can just

waitForResult.join()

instead, and it will work out of the box. In general, most usages of

advanceUntilIdle

that I've seen in the wild are not needed and can be replaced with plain and simple synchronization between coroutines, the way you'd write it in production code.

I made a reproducer:

class Test {
    @OptIn(ExperimentalCoroutinesApi::class)
    @Test
    fun test() = runTest {
        launch {
            println(1)
            delay(100) // skipped
            println(2)
            withContext(Dispatchers.Default) {
                delay(100)
            }
            println(3)
            delay(200) // not called at all on advanceUntilIdle
            println(4)
        }
        advanceUntilIdle()
        println("-------------")
    }
}

It prints the following:

1
2
-------------
3
4

I expect:

1
2
3
4
-------------

If you move

join

after

println(4)

, you'll get what you expect.

The

launch

is hided in view model. The

launch(Dispatchers.Default)

is actually a ktor post request, I changed it above to

withContext

. This is just a simplified example to show the problem.

but that's what I'd expect from an advanceUntilIdle - at the point of the join there is no more work to run on the test dispatcher - it has to wait for the non-test dispatcher to finish before there is more work to run

I think waiting for another coroutine is also some sort of "work". It is definitely not idle in my understanding, because there is still possible work in the future.

I feel that opinion goes against the grain a bit I'm afraid I am not sure why you wouldn't just rewrite it as

class Test {
    @OptIn(ExperimentalCoroutinesApi::class)
    @Test
    fun test() = runTest {
            println(1)
            delay(100) // skipped
            println(2)
            withContext(Dispatchers.Default) {
                delay(100)
            }.join()
            println(3)
            delay(200) // not called at all on advanceUntilIdle
            println(4)
        println("-------------")
    }
}

advanceUntilIdle

and others are unintuitive when other dispatchers come into play. This is only this way for historical reasons; if we designed the framework today from scratch, they wouldn't be included. That's one of the reasons why we are looking into providing suitable replacements for them: https://github.com/Kotlin/kotlinx.coroutines/issues/3919

I feel that opinion goes against the grain a bit I'm afraid

I am not sure why you wouldn't just rewrite it as

As mentioned above, the

launch

is hidden in a not suspending view model method. This is just an example to show the actual problem.

The official solution for such cases is to mock the dispatcher with a test dispatcher. See https://developer.android.com/kotlin/coroutines/test, "Injecting test dispatchers."

I know, but ktor deprecated setting it for MockEngine. I also found this behaviour of TestDispatcher very unexpected. We can never know, if a thirdparty library makes a context switch and then

advanceUntilIdle

is just useless.