Hey guys :slightly_smiling_face: In JUnit running stuff in a test scope is pretty straightforward: `...

# kotest

[wasyl]

Hey guys 🙂 In JUnit running stuff in a test scope is pretty straightforward: @Test fun someTest = testScope.runBlockingTest { }. Is there some well-established pattern for running specs in a test scope? For example, do you wrap topmost test block, or maybe each smaller scope separately?

Would it make sense if Kotest facilitated (or maybe it does?) running tests with coroutines in a test scope, by allowing injecting it or providing. I don’t think there’s any configuration regarding that though, is there?

[sam]

You can just run a coroutine directly in kotest.

[sam]

test("some test") {
  delay(1000)
}

[sam]

You can even launch child coroutines directly.

test("some test") {
  delay(100)
  launch(<http://Dispatchers.IO|Dispatchers.IO>) {
     delay(200)
  }
}

[wasyl]

That’s right, but as far as I understand I want to use testCoroutineDispatcher if I’m testing code that launches another coroutine inside — to check that all jobs complete etc. For example this intro video about corutines suggests running test on the same dispatcher that’s injected to the tested class:

[wasyl]

[wasyl]

I’m only starting with coroutines so I’m not exactly sure why it’s the same dispatcher and whether it’s actually necessary

[wasyl]

But from what I understand wrapping code in testDispatcher.runBlockingTest will do some verifications regarding leaking/uncompleted coroutines/jobs

[sam]

I don't know anything about the testDisaptcher. If all it's used for is to detect that child coroutines finish, then kotest does that as well, it waits for any launched child coroutines.

If testDispatcher does more than this, and you want to use it, you could just do what that screen grab is doing and use testDispatcher inside the test body.

[wasyl]

Got it 🙂 I suppose Kotest waiting for launched child coroutines is the most important bit. I’ll be back when I understand coroutines better 😛

[sam]

Yeah if you find out what that test dispatcher does, we can look to integrate it if it's useful

[sam]

(maybe allow people to specify the dispatcher in config or something)