Ah ok, thanks! Wasn’t sure if the kotest runner would complain.

I swore that test contexts (

context

in

ShouldTest

) were in a coroutine scope, but noticing I can't call

launch

in there...am I missing something? Or do I need to create my own?

they're all coroutine contexts ?

@bbaldino just tried this

should("a test") {
   1.shouldBeLessThan(2)
   launch { delay(100) }
}

and

context("a context") {
   should("a test") {
      1.shouldBeLessThan(2)
      launch { delay(100) }
   }
}

ah, i didn't have it within a

should

Although we should probably have context itself being in a context, @sam

context is a context

If, for example, I have suspended variables to calculate inside context, not shoulds

I mean, a suspended scope, idk what I said over there

wait its not

I think that's the issue Brian reported

It should be tho, probably just forgotten 😅

Yeah, would be nice

I'm sure it used to be

but it can't have been or we'd have had tests for it

I think I can do it fairly easily

Let's add it to 4.1

While I'm asking...is the coroutine that drive tests backed by a single thread? Or a multithreaded dispatcher? I have to do some blocking work and wondering if I should explicitly use

<http://Dispatchers.IO|Dispatchers.IO>

or not

it uses its own

https://github.com/kotest/kotest/issues/1488 <-- your original request

But does the test's own have multiple threads? Or just one?

we create a single thread that is then used by all tests

Ok, thanks

if you have a test that blocks though

even if you move it out to another dispatcher, kotest won't move onto the next test until that first test completes

because that coroutine scope must complete

Yeah that's fine

wondering if anyone here has any successful experience with spring’s

@DirtiesContext

- i’m annotating my integration tests with

@ContextConfiguration(initializers =

pointing to an initializer to initialize my beans declared with the kotlin functional bean DSL but by the time the second Spec executes, it just references the cached context and doesn’t recreate the

ApplicationContext

(which sets up test containers and connection pools etc)

@DirtiesContext(classMode = DirtiesContext.ClassMode.BEFORE_CLASS)

or

@DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS)

does nothing by the looks of it