What's the recommendation when wanting to use `checkAll` , or something like it, but when more than ...

# kotest

[julian]

What's the recommendation when wanting to use checkAll , or something like it, but when more than 12 values need to be generated at once?

[sam]

Make a PR to add 13, 14, etc 😛

[Emil Kantis]

You could bind several values into a fixture class.. like:

data class Fixture(a: Int, b: String // etc)

checkAll(Arb.bind<Fixture>(), [other arbs]) { (a, b), [ other values] -> 
 }

[julian]

Make a PR to add 13, 14, etc 😛

If it won't be rejected on principle alone, I will. Just wouldn't want to do a bunch of work that's rejected for reasons other than implementation choices.

[sam]

It wouldn't be rejected if you just copy n paste the 12 arity one and make a 13 arity one, etc

[julian]

That's exactly what I had in mind...

[julian]

I want to go up to 22. You game?

[julian]

Btw, I'm interested in this because we have 22-arity functions in Arrow, which I need to write tests for.

[sam]

yes lets do it

[sam]

all the way to 22

[julian]

Right on!

[julian]

@Sam I don't see an existing issue, so I'm going to create one.

[sam]

ok

[sam]

I'll be releasing 5.5.5 tomorrow so we can include this if it's ready in time

[julian]

Bummer. It's going to be at least a few days before I have this. But thanks for the heads up.

[sam]

Ok well 5.6 will be released shortly after, as a Kotlin 1.8 release

[julian]

Awesome! 🚀

[Adam S]

I notice quite a bit of lag in IntelliJ when the autocomplete for checkAll() is loading, which I suspect is related to the large amount of overloads that have lots of generics. Can you make sure that the performance is okay when you try increasing it please?

[Emil Kantis]

Great point adam.. I have had issues with that too 😬

[sam]

I wonder if we could reduce the number of overloads, there's loads that have config/not config etc

[julian]

Can you make sure that the performance is okay when you try increasing it please?

@Adam S Do you have suggestions how to do this? What's the standard to compare to?
@sam Could this be a limit on going to 22-arity?

[sam]

We do have a billion overloads, so I would only add more for the ones in this format:

suspend fun <A, B> forAll(
   config: PropTestConfig = PropTestConfig(),
   genA: Gen<A>,
   genB: Gen<B>,
   property: suspend PropertyContext.(A, B) -> Boolean
)

[sam]

And not these ones:

suspend fun <A, B> forAll(
   iterations: Int,
   genA: Gen<A>,
   genB: Gen<B>,
   property: suspend PropertyContext.(A, B) -> Boolean
)

[sam]

And not the ones that infer the types,

suspend inline fun <reified A, reified B> forAll(
   crossinline property: PropertyContext.(A, B) -> Boolean
)

[sam]

If you want to use 20 arbs that's fine, but you can specify them. I think that's a fair tradeoff.

[julian]

Okay, will do @sam.
What about the `checkAll`s and `forNone`s? Same pattern for which overloads to not include?

[sam]

yeah

[julian]

And ignore these too?

suspend inline fun <reified A, reified B, reified C, reified D, reified E, reified F, reified G, reified H, reified I, reified J, reified K, reified L, reified M> checkAll(
   noinline property: suspend PropertyContext.(A, B, C, D, E, F, G, H, I, J, K, L, M) -> Unit
)

[julian]

I have a draft PR. Please let me know if all looks good, so I can replicate to remaining arities. Thanks!

[sam]

Yep looks good

[julian]

Cool. Thanks!

[julian]

@sam Regarding tests for the code I'm adding, I've found CheckAllExhaustivesIterationTest, PropTestConfigConstraintsTest, and ForAllExhaustivesIterationTest, that I need to add tests to. Any others you know of? Thanks!

[sam]

That should be sufficent.