for-all should support nesting


Haskell QuickCheck allows for-all expressions to nest. This is useful when there are dependencies between generated values. test.check should allow this, too.

Currently, nested for-alls always succeed, which is somewhat pernicious.

I've added a patch that implements this.




October 4, 2015, 3:47 PM

We've been thinking about a similar problem in TCHECK-81, and in the meantime there's an even-fancier variant of for-all here.

October 4, 2015, 10:42 AM

Comment made by: expez

I don't really want to have to nest for-all, I'd much rather prefer it work like let where we can refer to previous values. That said, no matter which solution, this is my biggest gripe with test.check at the moment, so any solution would be preferable to another year of hammock time.

Here's one solution, taken from the wild. I'm sure there are many others, people want this badly, but this one was taken from Nathan Marz's specter library:

Reid Draper
October 29, 2014, 4:55 AM

Looks OK. However, it's difficult to see why that would get you more quickly where you said you want to go than my patch ...

Fair enough. Part of this it that it was easier for me to write up a sketch. The main things I'm trying to cover when supporting nested generators are making sure:

  1. We also support the upcoming ability to collect and return statistics about a test, ala collect from Haskell QuickCheck

  2. We have a sane way of returning failing tests to a user. Right now, in the :fail and :smallest keys of the returned map, we tell the user the failing arguments. They're always wrapped in at least one vector, since you may use more than one generator using prop/for-all. What do we do with nested properties? How do we distinguish between multiple generators at the 'same level', vs nested properties? Or do we not need to distinguish? Can whatever we decide to do be backward compatible?

Point being, I want to make sure we're not committing ourselves to nested-properties until we have some of those answers, and for me personally, it's easier to try and play with these things together, and see how they will fit together.

October 22, 2014, 8:00 AM

Comment made by: sperber

Looks OK. However, it's difficult to see why that would get you more quickly where you said you want to go than my patch ...

Reid Draper
October 22, 2014, 4:23 AM

Sorry for the delay, here's my sketch I've been working with:










Code and Test