as in the rest why asserAll/forAll are not suspend...

# kotest

[Dias]

as in the rest why asserAll/forAll are not suspend functions?

[wasyl]

There is a forall variant in suspend package, so maybe you’re importing wrong version?

[wasyl]

io.kotlintest.data.suspend.forall

[simon.vergauwen]

Why separate them?

[simon.vergauwen]

Good to know, first I heard about this as a long time KotlinTest user 😄

[Dias]

that's for data driven test right?

[Dias]

I need generators tho

[simon.vergauwen]

forAll(<http://Gen.int|Gen.int>(), Gen.string()) { int, string ->
   ...
}

[simon.vergauwen]

I do property-based testing with forAll

[Dias]

which is not suspendable

[sam]

They were not suspendable because they existed before coroutines did and we couldn't just change it after. But in 4.0 because it's a major change they have become suspendable

[sam]

So tldr wait for 4.0 or try the beta :)

[AJ Alt]

Although I understand the elegance of making all the table tasting functions suspend, that change means they can't be used in non-suspending contexts. Some large teams at Microsoft make extensive use of forall with a JUnit test runner. 4.0.0-BETA1 is unusable for them.

I think we should either make forAll non-suspending, but take a suspending lambda, or continue to provide both suspending and non-suspending versions of the functions.

[sam]

You can't take a suspend lamba and run it in a non suspend function I don't think

[sam]

Let me think about what we can do. Maybe inlining is a solution

[sam]

Maybe just duplicating them like before is the solution

[simon.vergauwen]

You can’t take a suspend lamba and run it in a non suspend function I don’t think

You can if you implement a basic runtime for suspend like Arrow Fx and KotlinX do. Or you need to wrap in IO or Deferred so you can delay executing the suspend from a non-suspend function.

[simon.vergauwen]

I.e. if forAll becomes a DSL a nested DSL of TestCase, that way your suspend is wrapped in TestCase and you can run them yourself later however you want

[simon.vergauwen]

Wouldn’t something like that work?

[simon.vergauwen]

Sounds like a very interessing design challenge 😬

[sam]

I think the problem is it needs to work outside of KotlinTest/kotest. That's why having the suspend is a problem as junit doesn't understand it,

[simon.vergauwen]

Yes, but that is why building your own suspend runner would solve your problem. Which is quite easy to do.

[simon.vergauwen]

You can make Junit understand with an adaption layer that has a suspend runner, no?

[simon.vergauwen]

Whenever interpreting TestCase into junit

[AJ Alt]

It looks like ultimately all these suspend functions get called with runBlocking in the KotestEngine.

What if we changed to forall to work like

fun forAll(vararg rows: Row, testfn: suspend (...) -> Unit) = runBlocking {...}

That would allow you to pass in suspend functions, but call forAll from a blocking context. The behavior would stay the same as it is right now.

[simon.vergauwen]

That would hinder accumulating them and running them in parallel, no?

[sam]

It would stop the thread that’s being used yeah. I guess if we allocated each test a separate thread from Dispatchers.IO then it wouldn’t really matter.

[sam]

We already allocate a thread per Spec actually (or at least share threads were parallelism is used).

[sam]

I guess the downside is if you want to use a coroutine inside forAll and suspend, while running something outside of it, in the same test scope. But what are the chances of that.

[simon.vergauwen]

I guess if we allocated each test a separate thread from Dispatchers.IO then it wouldn’t really matter.

That sounds dangerous