Feature request: out of the box `theories`

[luav]

Theories precisely express software properties over potentially infinite sets of values and provide concise validation of the code logic.
Criterion unit test framework provides pretty good implementation of the theories, which makes it an ultimate choice for math libs and some other projects. Theories can be emulated in mettle using expressive syntax of expectations and matchers but mettle lacks out of the box support of the basic theory rules. Integrated and explicit availability of the most frequently used theories (the list could be fetched from the Criterion) would further speed up and simplify unit testing with mettle.

[jimporter]

This sounds like it would be pretty trivial to implement as a parameterization on expectations. I'm not sure it's something I'd want in mettle proper (it's bad enough that I have a test definition framework, test runner/aggregator, assertion/expectation framework, and output-formatting tools in one lib!), but I could see doing something like this in a separate library. That's the way I did things for compilation-testing (i.e. making sure that certain code compiles/doesn't compile) with caliber, which integrates with mettle's test aggregator.

Are you just suggesting I add something like an assume() function that lets you easily exclude certain sub-cases from a test? I guess an easier way to define multiple expectations could help too, but those are designed to be easy to define via a for loop.

[luav]

Thanks for the clarification. Jim, is there any documentation for caliber functionality?

No, the idea is not just to exclude some sub-cases from the test, which can be performed by the filter matcher. What lacks in mettle (or at least I'm not aware about this feature) and what provide theories is the ability to test a specific behavior against permutations of a set of user-defined parameters available out of the box. It can be relatively easy implemented by the expectation caller but:

1. It should be perceived by the user as a single test rather than set of tests.
2. It is convenient to have such feature out of the box rather than implement it by your own.

The theories functionality can be implemented as either a function that calls expect and matchers or as an extension of the expect function with the additional parameter that is a container of the permutating items being supplied as parameters to the expecting and matching functions (expect parameters). Alternatively, the latter can be implemented as a new function that provides extended functionality of expect. The application of theories often includes filtering, so there is no sense to make redundant permutations that will be filtered out, which could be optimized having access from the theories implementation to the filtering logic.

[jimporter]

caliber is still a demonstration, so its "docs" are just the test folder in the repo. I hope to get back to working on that later this year though...

As for this issue, I'll see if there's something I can do about it...