But I'm not sure if it's possible

# kotlintest

[LeoColman]

But I'm not sure if it's possible

[dave08]

@LeoColman What problem are you currently having with it?

[LeoColman]

I'm not very used to coroutines yet, and I don't really know how they work

[LeoColman]

I'm afraid to put everything in a runBlocking block and it bugs someone's code

[LeoColman]

For instance giving every Spec and TestContext a CouroutineScope

[dave08]

The advantage of coIt is that it gives the user the choice to use coroutines support, too much magic sometimes leads to hard-to-reason-about testing...

Mockk.io does it like that, and Spek doesn't even want to introduce support, so I ended up making my own functions.

The coroutine scope is usually at the base of the whole hierarchy, it is responsible for canclelling all the child jobs and cleaning up.

[LeoColman]

Do you think it would be better to add a co { XX } block instead of giving Coroutines to everybody?

[LeoColman]

I personally find adding coIt and similar useless, as the user can add runBlocking inside the code, and the extra line of code would be the very same

[dave08]

Also extra nesting...

[LeoColman]

One extra nesting, you're right

[LeoColman]

The problem with coIt, as you mentioned in the GH Issue is that it wouldn't apply for everything, such as FreeSpec

[dave08]

Right... that's where I got stuck.

[dave08]

But an infix co could fix that

[dave08]

It just needs to be applied to the test itself, not the groupings...

[LeoColman]

https://github.com/kerooker/kotlintest

[LeoColman]

This is what I've been trying so fare

[LeoColman]

I'm thinking that having all the scopes as suspended might be a good idea, but I'm not sure how to validate that.

[LeoColman]

I'm fixing the scenarios that SKSamuel setup, but I'm not sure if that's enough

[LeoColman]

That branch is kind of confusing, I'm doing some refactorings in the SpecRunner to allow for that suspended context

[dave08]

Ktor also runs completely on coroutines, and all the routes have scopes. You need to make sure that a launch or async that fails in one test or test class doesn't cancel all the others... isActive can be called in a suspend function to see if its still active and launch has a job you can test.

[dave08]

This seems to be their "root" https://github.com/ktorio/ktor/blob/master/ktor-server/ktor-server-core/jvm/src/io/ktor/application/Application.kt . Notice the SupervisorJob to avoid one failing request to cancel the others...

[dave08]

And it gets disposed by cancelling only the root scope, which in turn cancels all the children..

[LeoColman]

Could you help me elaborate a test case that exercises that? I can't think of code that tests that

[dave08]

I just had a VERY funny bug (maybe with my coIt...?) that when I added a test function, junit runs the old ones, and doesn't find the new one... tried clearing/invalidating IDE and gradle caches, to no avail...

[dave08]

For an example, I'm not too sure what you need... I'm not too familiar with junitPlatform. I think that using the same SupervisorJob at the root, and launch a coroutine for each parallel test (with a new thread.asDispatcher()) and then surrounding each test in a coroutineScope { } builder might do the trick (to ensure all the cancellation is handled properly), the thing is that I don't know where the tests are actually executed (in TestEngine?), there you might need a single runBlocking to wait for everything to complete (it might be the one to use the SupervisorJob...).