https://kotlinlang.org logo
#kotest
Title
# kotest
j

Jonathan Olsson

05/17/2021, 7:11 PM
Are there any future plans to extend
io.kotest:kotest-property
with stateful testing? 🙂
s

sam

05/17/2021, 7:16 PM
Example ?
j

Jonathan Olsson

05/17/2021, 7:18 PM
A well written test scenario with statem is like black magic.
s

sam

05/17/2021, 7:19 PM
Ahh I have seen this before. I didn't quite get the usefulness of it at the time.
so it basically tests actions against input
j

Jonathan Olsson

05/17/2021, 7:24 PM
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.
s

sam

05/17/2021, 7:26 PM
I like the idea
I wonder if we could do something better than that ugly set of interfaces that is forced on jquik by the fact its java
👍 1
j

Jonathan Olsson

05/17/2021, 7:27 PM
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)
Actually, perhaps this is the best introduction to describe the design rationale and potential usefulness: https://proper-testing.github.io/apidocs/proper_statem.html
s

sam

05/17/2021, 7:48 PM
I will read all this material see what comes to mind
thanks for the suggestions
j

Jonathan Olsson

05/17/2021, 7:54 PM
It's me who should thank. 🙂 Was struggling with arcane java libraries before I found kotest. 😛
s

sam

05/17/2021, 7:55 PM
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
❤️ 1
d

dave08

05/18/2021, 12:15 PM
j

Jonathan Olsson

05/18/2021, 12:26 PM
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.
d

dave08

05/18/2021, 12:30 PM
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.
j

Jonathan Olsson

05/18/2021, 12:36 PM
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.
d

dave08

05/18/2021, 12:39 PM
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...
I'm still struggling with the tons of dependencies and possible repository states with my regular testing...
And this is WITH having isolated functions into use cases and hexogonal architecture
j

Jonathan Olsson

05/18/2021, 12:40 PM
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. 🙂
👍🏼 1
👍🏻 1
3 Views