Are there any future plans to extend `io.kotest:ko...

# kotest

[Jonathan Olsson]

Are there any future plans to extend io.kotest:kotest-property with stateful testing? 🙂

[sam]

Example ?

[Jonathan Olsson]

http://quviq.com/documentation/eqc/index.html

[Jonathan Olsson]

Or https://jqwik.net/docs/current/user-guide.html#stateful-testing

[Jonathan Olsson]

A well written test scenario with statem is like black magic.

[sam]

Ahh I have seen this before. I didn't quite get the usefulness of it at the time.

[sam]

so it basically tests actions against input

[Jonathan Olsson]

Basically yes. In erlang I know the actions are defined as symbolic command sequences that gets randomly selected for execution. Naturally, preconditions may be set to assert invalid call sequences does not occur.

[sam]

I like the idea

[sam]

I wonder if we could do something better than that ugly set of interfaces that is forced on jquik by the fact its java

[Jonathan Olsson]

Here is an (erlang) tutorial with an open source rip-off of the eqc library (https://proper-testing.github.io/tutorials/PropEr_testing_of_generic_servers.html)

[Jonathan Olsson]

Actually, perhaps this is the best introduction to describe the design rationale and potential usefulness:

https://proper-testing.github.io/apidocs/proper_statem.html

[sam]

I will read all this material see what comes to mind

[sam]

thanks for the suggestions

[Jonathan Olsson]

It's me who should thank. 🙂 Was struggling with arcane java libraries before I found kotest. 😛

[sam]

Well that's why it exists 🙂 When I started the project I was a Scala developing looking to use Kotlin and was terrified I'd have to go back to junit after the beauty that was scala test

[dave08]

Is this the same idea @Jonathan Olsson? https://medium.com/default-to-open/property-based-testing-in-kotlin-part-4-e3a06eab3910

[Jonathan Olsson]

Seems like it. Ideally you need a more expressive approach though I guess. The generation of testcases need to be agnostic to the state of the system in order to efficiently shrink and to create repeatable tests so they need to be somewhat symbolic. You need some way to model the expected state of the System Under Test (SUT) as well as a way to filter valid actions based on the model state.

[dave08]

Well, it seems from that post though that with a few support interfaces it can even be done now with Kotest... for sure it would be better to be built in the library though.

[Jonathan Olsson]

Yeah, as mentioned, you need more than a few supporting interfaces. command generation (with shrinking), state transfers, preconditions and postconditions I guess are the essential parts. How to bundle that in a nice coherent kotlin-idiomatic way is the hard part.

[dave08]

Btw, thanks for bringing this up 🙂, I never seemed to catch on to property based testing, but when I saw that jqwik page you posted, I started looking at it seriously... I currently have a project that it could be a tremendous help in...

[dave08]

I'm still struggling with the tons of dependencies and possible repository states with my regular testing...

[dave08]

And this is WITH having isolated functions into use cases and hexogonal architecture

[Jonathan Olsson]

People who get good at PBT can really root out such insane bugs. I've seen it happen where weird concurrent race conditions in data bases getting reproduced in a reliable fashion through eqc. It is a very difficult thing to do right, but man is it under appreciated. 🙂