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

Better document/fix shrinking API #218

Closed
sir4ur0n opened this issue Feb 20, 2019 · 4 comments
Closed

Better document/fix shrinking API #218

sir4ur0n opened this issue Feb 20, 2019 · 4 comments

Comments

@sir4ur0n
Copy link
Contributor

sir4ur0n commented Feb 20, 2019

Hi,

I have written a library of generators for Vavr, and I'm now addressing the shrinking part.
The shrinking API is weird and not enough documented. Here's a list of proposals:

  1. Why try bigger values before smaller values?
    See QuickCheck documentation on shrinking: it tries smaller values before bigger values, which makes more sense (don't bother testing a huge list of N-1 elements if an empty list already blows up).

  2. Support a lazy structure: doShrink must return a java.util.List which has only strict implementations in the JDK AFAIK. Building a list of shrinks may be CPU-heavy, and if the first value doesn't pass, then we discard everything and start shrinking again from the slightly smallest value.
    If we could return a lazy structure (e.g. a Stream), this would significantly improve the shrinking process.

  3. Provide an easy way to log/understand what happens during shrinking, much like QuickCheck provides a verbose mode which details every step (passed, failed, shrunk, etc.).

Passed:
[]
Passed:
[]
Passed:
[]
Failed:
[2,2]
Passed:
[]
Passed:
[2]
Passed:
[2]
Failed:
[0,2]
Passed:
[]
Passed:
[2]
Passed:
[0]
Failed:
[0,0]
Passed:
[]
Passed:
[0]
Passed:
[0]
*** Failed! Falsifiable (after 4 tests and 2 shrinks):
[0,0]
Use --quickcheck-replay=249810 to reproduce.

If it already exists, providing documentation to detail this would be nice 😄

Let me know if you want me to open several issues.

@pholser
Copy link
Owner

pholser commented Feb 21, 2019

@sir4ur0n Thanks for your interest! I will look into these requested changes.

@pholser
Copy link
Owner

pholser commented Feb 26, 2019

@sir4ur0n For 1), you're right -- there's no particular reason to try larger shrinks before smaller ones.

  1. I agree that laziness would be more useful. Also, what you said about abandoning generated shrinks as soon as a smaller counterexample is found from among them sounds reasonable, even if we were to continue yielding Lists from doShrink.

  2. Also reasonable.

These three sound like each might be valuable independent of the others. What do you think about having separate GH issues for each?

@sir4ur0n
Copy link
Contributor Author

I propose we address 1) through #219

  1. can be addressed in Shrinkers should be able to provide a Stream #220

  2. can be addressed in Provide optional step-by-step logs #221

Then we can close this issue :)

@pholser
Copy link
Owner

pholser commented Feb 26, 2019

Agreed. Closing this one. Thanks!

@pholser pholser closed this as completed Feb 26, 2019
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

No branches or pull requests

2 participants