Repository navigation
Implement integrated shrinking à la Hedgehog? #403
Description
FsCheck is a great library, but AFAIK it does not do integrated shrinking as explained in this post. If this is true, then AFAIK shrinking does not necessarily satisfy the same invariants as generation.
This is probably too huge a change to even be considered (and my skills are certainly not up to the task), but I'll ask anyway: Could integrated shrinking be implemented in FsCheck? Hedgehog already does this, but is not as mature as FsCheck and has some other problems (most notably terrible performance).
Reacted by Michael Fry and Mauricio Scheffer
Activity
kurtschelfthout commentedon Oct 11, 2017
I think this is a good idea. It's definitely a nicer wrap around the whole API. I read that post on hypothesis before and was initially put off because I thought it was a bit hyped up. I still don't think the contrast between approaches is as stark as put in that blog post, but anyway, let's not start a flame war.
Basically FsCheck has already 95% if not 100% of the functionality, but what those newer iterations of QuickCheck do is wrap everything up in a
Propertymonad from the start. FsCheck currently patiently first definesGen<'a>+ API which allows you to just generate random values. Then it turns that intoGen<Rose<'a>>which allows you to shrink those values. Then it turns that intoGen<Rose<Result>>which allows you to test, and is supported by thePropAPI. And then theArbitrarywas first conceived as a registration mechanism for generators/shrinkers, while really all the primitive generators/shrinkers should be available at the level ofGen. All of that is basically how hedgehog works - the only type you really interact with from the start isGen<Rose<Result>>and so the whole thing becomes just one API for generating/shrinking/testing.So it is a significant refactoring, for sure. But it doesn't need any new functionality or deep changes, as far as I can tell.
I'd like to try to prototype at least for v3, but might want to chew on #396 a bit first.
cmeeren commentedon Oct 12, 2017
Another nice thing about this is that it would allow a more Hedgehog-like syntax of defining generators in terms of existing generators and generator combinators (I assume this is because generators are monadic or something like that, as opposed to arbitraries), and still get shrinking. To me, building up generators "from the ground" using primitive generators and combinators feels nicer than starting with arbitraries and filtering them, but that may just be subjective.
The best would be to have both Hedgehog's robust and flexible syntax for defining generators, and FsCheck's ability to automatically generate whichever type you want without specifying every single thing.
I would love to have this in v3!
nth-commit commentedon Aug 29, 2019
I'm a sample of size 1, but it didn't take me long to realise that this is a deal-breaker for me (at least in the current project I'm working on). I went down the path of having to write unit tests for my shrinkers to ensure they conform to my generators. Then I stumbled upon "integrated shrinking" and subsequently Hedgehog. Would love this feature in FsCheck.
jzabroski commentedon Aug 29, 2019
I agree. I think Hedgehog has the superior approach but I stayed away from it due to lack of community involvement. FsCheck has the community, Hedgehog has the technology. I always side with community until some big brain comes around and changes the game, then I jump ship.
hroe commentedon Oct 2, 2023
Hi, did fscheck v3 include support for integrated shrinking?
kurtschelfthout commentedon Oct 2, 2023
@hroe no, didn't make it in.