https://kotlinlang.org
Join Slack
Hello! After upgrading the Kotest version to 4.3.1 (from 4.2.2) I have noticed that it takes double ...
# kotest
a
Hello! After upgrading the Kotest version to 4.3.1 (from 4.2.2) I have noticed that it takes double the time to run the tests. I am heavily using the property based tests and I see that now there are much more edge cases. I was told that using a 
filter
can be the cause of slowing down. Do you also think that using 
bind
is the problem? Maybe I should try to avoid both and use 
arbitrary
instead of 
bind
?
s
Do you have an example of a test that has slowed down?
a
Not a specific one. We have a lot. I had to go over 
string
for example and change them to 
pattern
to avoid lots of non relevant cases.
s
The edge cases with bind did change recently
a
We use 
bind
a lot
yes it can explain. so what is the alternative to 
bind
? can I try the 
arbitrary
instead?
s
previously bind wasn't doing the edge cases very well, but now it generates the edge cases from the generates passed in
arbitrary is just the name for generators that provide random values
are you doing something like Arb.bind<Person>(Arb.String, Arb.Int) { ... }
a
yes - so let me correct myself - the tests are not slow they are just creating much more cases
s
yep that will be because the edge cases are now generated for bind'ed arbs.
a
yes but imagine that we have a Person with lots of classes inside
s
can you paste me one of your binds
rename the fields / types if it's sensitive
a
Copy code
Arb.bind(UserGen,
Arb.string().filterNot { it.contains('@') }
 )
and imagine that the UserGen is another Arb that internally is built from other Arbs that are created by other 
bind
s
so what you can do is just remove the edges manually
Copy code
Arb.bind(
  UserGen,
  Arb.string().filterNot { it.contains('@') }
 ).withEdgecases(emptyList())
I can add a feature into 4.3.2 to make that a bit easier
a
like you have a class inside a class inside a class and to build the huge one you need lots of binds
yes I have heard of this (remove edge-cases) but I am not sure if this is good to ignore them - they might be good to find problems
s
you can't have it both ways 🙂 Either you want the edgecases or they are generating too many tests.
a
I am thinking maybe if I could set that I want maximum 10 edge cases randomly
s
ok
Copy code
Arb.bind(
  UserGen,
  Arb.string().filterNot { it.contains('@') }
 ).modifyEdgecases { it.take(10) }
a
so the other question I had was about 
arbitrary
is it better than 
bind
s
that's like asking if generator is better than string
bind returns an arbitrary
👍 1
a
wow I think this will be great to take just 10 🙂
s
Copy code
An [Arb] (for arbitrary) is a provider of property test data in two categories: edgecases and samples
So 
Generators
are made up of 
Arb
and 
Exhaustive
Arb is all your random values and edge cases
👍 1
and Exhaustive is a specific set of data, like an enum or 1..100
.modifyEdgecases { it.take(10) }
is already in the code base
and you could add your own ext fun to make it easier to use.
Copy code
fun <A> Arb<A>.limit() = this.modifyEdgecases { it.take(10) }
Copy code
Arb.bind(
  UserGen,
  Arb.string().filterNot { it.contains('@') }
 ).limit()
You only need to do it on the outer bind, not inner binds
a
Yes! I thought so
thank you I will try and report back
👍🏻 1
Going to try this
Copy code
.modifyEdgecases { it.shuffled().take(10) }
s
ok
a
Hi @sam I forgot to update you. We found out that what was slowing the tests was Arb.pattern. I used a regex to find alphanumeric and it was a shocker to the system.
I can create a bug on github if you want
s
I think that pattern will always be slow.
Can create issue
a
7 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by