Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable QCheck2 shrinker with a parameter #232

Closed
vch9 opened this issue Mar 18, 2022 · 3 comments · Fixed by #253
Closed

Disable QCheck2 shrinker with a parameter #232

vch9 opened this issue Mar 18, 2022 · 3 comments · Fixed by #253

Comments

@vch9
Copy link
Contributor

vch9 commented Mar 18, 2022

That'd be cool to disable the shrinker with a boolean in Test.make for instance. I don't know if we can already do this or if it's impossible but this might be a really good feature.

It can happen that the test is wrong and since the generated value is really not-trivial, it takes a lot of time to shrink.

@jmid
Copy link
Collaborator

jmid commented Mar 18, 2022

On the one hand I'm supportive of this feature.
I've used set_shrink Shrink.nil some_gen in similar situations for "QCheck1" in the past.
One could go for a similar design for QCheck2 where the operation changes/removes the Tree children.

On the other hand, to me this indicates short-comings of the QCheck2 shrinkers.
I observed these and commented on them in #157 #163 and #153 (comment) while I was trying to test QCheck2 a bit.
We need example cases to reproduce and understand what is going on when shrinking takes too long in order to improve the situation. I understand that carving out those from a bigger project can require quite some effort though.

@vch9
Copy link
Contributor Author

vch9 commented Mar 18, 2022

I think I can extract one example pretty easily. One co-worker wrote a Merkle Tree or something, it shouldn't have too much dependency with our project.

@vch9
Copy link
Contributor Author

vch9 commented Jul 11, 2022

I think I can extract one example pretty easily. One co-worker wrote a Merkle Tree or something, it shouldn't have too much dependency with our project.

Well, you shouldn't trust my words.

Anyway, I feel that we need it even if the generator is not that long. It's very situational but sometimes, no shrinker is the best solution.
My dirty solution currently is:

  make_primitive
    ~gen:(fun rand -> generate1 ~rand gen)
    ~shrink:(fun _ -> Seq.empty)

I'll try to tackle this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants