hedgehog VS smallcheck

> - rose tree "integrated shrinking" (eg. Hedgehog) follows the constraints of the generators, but has issues with monadic bind.

We're at the limits of my amateur knowledge, but I believe this is a fundamental limitation of monadic bind/generators. Instead, you should prefer applicative generators for ideal shrinking. https://github.com/hedgehogqa/haskell-hedgehog/issues/473#is...

In other words, applicative generators do not use "results of generators to dispatch to another generator", but instead shrinking is optimal due to the "parallel" nature of applicatives (I'm using "parallel" in the monadic sense, and not the sense of article's "threading" sense).

I've had some PRs open on hedgehog for one and two months respectively. It looks like the maintainer isn't currently very active, which is fair enough. This isn't about criticizing him, and I'm not trying to take over the repo.

Testing libraries like hedgehog often run tests in parallel, so you may find related issues to work on.

Haskell has QuickCheck and Hedgehog, and dotnet has both as well. F# is favored, but there's C# interop.

Using laziness to avoid generating parts of an expression until it's needed is a really nice idea. The LazySmallCheck package[1] took this approach, but was limited in the types of data it could produce (e.g. it couldn't generate functions). This was extended by LazySmallCheck2012[2], but that seems to be unmaintained and doesn't work with more recent GHC versions.

(Note that these are named in reference to SmallCheck[3], which takes the approach of enumerating concrete values in order of "size"; as an alternative to the more widely-used QuickCheck[4], which generates concrete values at random, and tries to "shrink" those which trigger a failure)

[1] https://hackage.haskell.org/package/lazysmallcheck

[2] https://github.com/UoYCS-plasma/LazySmallCheck2012

[3] https://hackage.haskell.org/package/smallcheck

[4] https://hackage.haskell.org/package/QuickCheck

Could you compare with https://hackage.haskell.org/package/smallcheck in particular the smallcheck ability "to verify properties for all test cases up to some depth"?

Another strategy is exhaustive generation. There, all possible values for some type are generated in some well-defined order - typically from "small" to "large" values, and with some upper bound, as once you go past booleans the number of values for most types are (countably) infinite. For example, trying all the integers between -20 and 20 in "zig zag" order 0,1,-1,2,-2,.... SmallCheck for Haskell and SciFe for Scala do this, but this approach is not so well-known. It's a shame as random and exhaustive generation are complementary - if you think of generating values as exploring some large space to find failing tests, random generation is a serendipitous type of exploration, while exhaustive generation is diligently mapping out all the paths in some area.