OliverO2

IIRC, passing system properties to the main Gradle task usually does not work with tests. Gradle forks another JVM for the test runner and fails to pass system properties. If...

> Nevertheless [your docs](https://kotest.io/docs/framework/conditional/conditional-tests-with-gradle.html) probably should be updated. Agreed.

@AlexCue987 There is already an ongoing discussion on [kotlinlang Slack](https://kotlinlang.slack.com/archives/CT0G9SD7Z/p1717034415006099?thread_ts=1707420378.970499&cid=CT0G9SD7Z). We'll have to look at integrating this with the Clue infrastructure and look at how to best combine power-assert output...

> Normally, kotlinx-coroutines-test awaits all foreground coroutines before ending the test. Is this documented somewhere? Kotest has no notion of "foreground" coroutines. A test function is a `coroutineScope { ......

I have never looked into IJ plugins, but do we have something like with K2 compiler plugins (in derivatives of `CompilerPluginRegistrar`)? ``` override val supportsK2 = true ```

`ErrorCollectorContextElement` is a `CopyableThreadContextElement` which does a deep copy of the underlying `CoroutineLocalErrorCollector`. If we'd use a plain `asContextElement()` instead, we'd miss `ErrorCollector` isolation. The test ["concurrent withClue invocations should...

Could the failing tests be related to build cache issues, @aSemy?

Sure: Generally it works like this: `testTimeSource()` provides `TimeSource.Monotonic` under normal circumstances, so we're using real time. But, if we're enabling the test dispatcher for a coroutine (hierarchy), then `testTimeSource()`...

We didn't need to change `TestCaseExecutor`. Using two-tier testing with `TestEngineLauncher.async` turned out to be sufficient. Added a commit to that effect. You can revert if you don't like it.

I like the approach. Some initial thoughts, intentionally not looking into the implementation, trying to suppress existing knowledge about property testing, and trying with a fresh look. I am aware...