<@U6P03BM0W> I think that this should be doable wi...

# minutest

[dmcg]

@dave08 I think that this should be doable with the transforms abstraction built in, but TBH I’m scared of messing it up as I have never used coroutines concurrency in anger. If you can feed me some use-cases I’ll have a think.

[dave08]

Just very simple testing of suspend fun calls and flows... the truth is, I'd suppose that surrounding each test with https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/run-blocking-test.html might be enough, but I don't know if that's what everybody might want in every case...

[dmcg]

Yeah, that’s my problem too! As I see it testing coroutines is so much more than just waiting for them to finish that you’re always going to want access to the runBlockingTest scope explicitly

[dave08]

But it could be provided as a this or it or are they both being used?

[dave08]

Also in Ktor, they used this (the receiver of the lambda) as an object providing a few things, including a call property...

[dmcg]

We are using both, this for the fixture, it for a TestDescriptor. We could add things to the TestDescriptor, but I’m wary of making changes like that that I can’t back out.

[dmcg]

Especially when I don’t really understand the use cases

[dave08]

In Mockk, they have every { } and coEvery { } for non-coroutines, and coroutines mocking... you could technically have an extra experimental function like that too with a special TestDescriptor for it...

[dmcg]

ATM we have

fun test(name: String, f: F.(testDescriptor: TestDescriptor) -> Unit): NodeBuilder<F> =
        test_(name) { testDescriptor ->
            this.apply {
                f(testDescriptor)
            }
        }

[dmcg]

I could imagine saying

fun test(name: String, f: suspend F.(testDescriptor: TestDescriptor) -> Unit): NodeBuilder<F> =
        test_(name) { testDescriptor ->
            this.apply {
                testDescriptor.coroutineContext.runBlockingTest {
                    f(testDescriptor)
                }
            }
        }

[dmcg]

which I think would be backwards compatible

[dmcg]

But

[dmcg]

anyone that writes a real coroutines test is going to end up pulling the TestCoroutineScope from the testDescriptor in order to call things like advanceTimeBy, in which case just adding your own runBlockingTest is a minor inconvenience?

[dmcg]

As I say though, I don’t really know. Please do try to write some real-world coroutines tests and let me know where the pain is.

[dave08]

The main pain is really the extra nesting everywhere... and to retrieve a scope could be just a question of an extension property/function testScope on TestDescriptor to avoid having to write all that ...

[Uberto Barbini]

I think a CoroutineContext would work... but I'm struggling to see the use case so I won't try to implement it

[dave08]

I'm struggling to see the use case

?

Do you write tests for Coroutines? You don't mind having to nest an extra runBlockingTest { } within each step of the test?

[dave08]

I think all that nesting makes tests look much more messy... in JUnit it's just:

@Test fun testSomething() = runBlockingTest { ... } so it's just one level, but in a DSL it makes things VERY hard to read.

[dave08]

I'm currently using KotlinTest which already implemented this, but I just don't really like the extra bloat of all those matchers in my namespace, and the fact that Fixtures aren't first class citizens...

[dmcg]

I think you could add an extension function to TestContext to achieve this

[Uberto Barbini]

my concurrent tests are quite complicated and they cannot be "just wrapped"

I never had the need to test a single suspendable fun :)