I'm running into an issue where I'm using `runBlockingTest` and `advanceUntilIdle` and I think it's ...

# kotest

[bbaldino]

I'm running into an issue where I'm using runBlockingTest and advanceUntilIdle and I think it's fooling kotest into thinking the test has timed out

[bbaldino]

kotest complains about Test did not complete within 600000ms, but I watch the test and know it didn't sit for a minute

[bbaldino]

I'm using runBlockingTest within the top context block, maybe that's wrong. Trying to repro with a small example, maybe I'm doing something dumb.

[Shalom Halbert]

Can you share a code sample?

[bbaldino]

Yeah, trying to get something together.

[bbaldino]

Ok, I think this shows what I'm seeing

[bbaldino]

class FooTest : ShouldSpec({
    context("top") {
        runBlockingTest {
            context("middle") {
                context("bottom") {
                    launch {
                        delay(Long.MAX_VALUE)
                        latch.countDown()
                    }
                    advanceUntilIdle()
                    should("something") {
                        latch.count shouldBe 0
                    }
                }
            }
        }
    }
})

[bbaldino]

That will fail instantly, complaining Test did not complete within 600000ms

[bbaldino]

I'm guessing because the fake clock of runBlockingTest gets used at some point by kotest to check for timeout

[Shalom Halbert]

Is it possible that the amount of time is an issue? If you make the delay 590000, doe the issue persist? You could be impacted by the the advanceUntilIdle

[Shalom Halbert]

In which case, you'd need to increase the test's timeout period

[bbaldino]

Yeah that's what I'm guessing it is

[bbaldino]

Hm, even if I make the delay 30000, I see the same thing

[bbaldino]

Ah, it's probably because the withTimeout is effectively done within runBlockingTest, so advanceUntilIdle goes until that finishes as well

[bbaldino]

If I move runBlockingTest to within the "bottom" context, it's fine

[bbaldino]

That won't work so well with my real test, but, at least that probably explains what's happening

[sam]

what does run blocking test do ?

[bbaldino]

Is part of kotlinx-coroutines-test

[sam]

is that what provides advance til idle

[sam]

so you can test delays ?

[bbaldino]

It's basically a helper for testing coroutine code more deterministically

[bbaldino]

Yeah

[sam]

interesting

[bbaldino]

I was thinking of working around this by rewriting the test to avoid the nesting and just doing isolated test cases.

[bbaldino]

But where does the withTimeout get applied for a test case?

[sam]

it gets added every time a test block starts

[bbaldino]

Whatever adds the withTimeout would have to be outside runBlockingTest I think

[bbaldino]

Where 'test block' is defined as what? A should in this case?

[sam]

so withtimeout is added by the TestExecutor class in kotest, before user code is invoked

[sam]

yep, any kotest lambda block

[sam]

it will add a withTimeout at every level

[bbaldino]

Hm

[bbaldino]

It works with runBlockingTest wrapping a should block ok.

[sam]

so you might have more success in this case by using a flat structure, dropping the context

[bbaldino]

So maybe it's that it can't be outside a context

[bbaldino]

Yeah, looks like it

[sam]

it might be that the withTimeout runs and then there's another withTimeout for the nested scope

[bbaldino]

Yeah, some withTimeout must be run within the runBlockingTest, so it becomes a child of that scope, so then advanceUntilIdle advances until that finishes as well I think

[sam]

yep because you're putting the test coroutine context outside of context, so that's why