OliverO2

Thanks for the reproducer. I'll be looking into it, but I'm currently occupied with other tasks. Just give me a week or so.

The example above (reasonably) assumes that, in `beforeTest`, the expression `coroutineContext[CoroutineDispatcher]` will return the `TestDispatcher`. However, in the first invocation of `beforeTest` this is not the case. A shortened example:...

@smworks Two things here: 1. Your test function completes before `RandomClass` has launched its `GlobalScope` coroutine. When calling `launch`, you cannot always assume that it will start its job eagerly....

Dear bot: Do not close.

The inability to set `jvmArgs` makes it currently impossible to run BlockHound-enabled tests on JDK versions >= 13 via the plugin. [BlockHound#33](https://github.com/reactor/BlockHound/issues/33) requires the following workaround: ```kotlin tasks.withType().configureEach { //...

@ulrikrasmussen Just a hint that does not solve the original problem, but may help in your use case: You could use test filtering in the build script instead of prepending...

That's of course all valid and has been noted in https://github.com/kotest/kotest/issues/3672#issuecomment-1703885285 and https://github.com/kotest/kotest/issues/3672#issuecomment-1704310884. What the original test in question was trying to achieve can probably be best answered by @sschuberth....

Came up with another scenario: What happens if the timeout just occurs during a cpu-bound period, even if the coroutine is non-blocking otherwise? Seems like in this case `newSingleThreadContext()` also...

> In this case, you're supposed to call ensureActive periodically during your work. Otherwise, there's no way for withTimeout to cancel the block of code. (In my own code, 'm...

> Thanks, but how you avoid the test to really take "a long time" then? The test case should complete as quickly as possible. In this case you should use...