What's the benefit of using `coroutineTestScope` i...

# kotest

[Kirill Zhukov]

What's the benefit of using coroutineTestScope in kotest over kotlin's runTest directly? Is the main benefit that I can set coroutineTestScope = true once on entire spec instead of having to call runTest on each individual test? Anything else I'm missing?

[LeoColman]

Just double checking: If your code is not related to testing coroutines, you shouldn't need to touch the coroutines scope.

Doesn't really answer your question but might take you out of a rabbit hole 😂

[Kirill Zhukov]

Definitely testing coroutines in my case 🙂

[CLOVIS]

Calling runTest inside a Kotest test won't work for some platforms (e.g. JS) because the promise won't be propagated correctly to the parent

[CLOVIS]

On platforms where it does work (e.g. JVM), it creates a completely decorrelated scope that has no relationship whatsoever with the Kotest internal scope, so you cannot use any Kotest configuration for coroutines, and you may have issues with timeouts

[Kirill Zhukov]

Are these differences documented anywhere in Kotest docs by any chance?

[CLOVIS]

I don't know.

[sam]

Saves you use runTest everywhere, kotest provides the scope for you. It also allows you to add blocking = true into the config, and then it will detect non coroutine deadlocks. As well as having other cooperative multitasking timeout support.

[Kirill Zhukov]

That's very good to know, thanks!