Last 12 weeks · 7 commits
2 of 6 standards met
This change allows generators in a instance to be seeded via the environment. The main motivation is faithfully reproducing tests, i.e. with the same seeds. One common use-case would be automated bisects. For example, a CI system could provide a seed which is stored alongside the report. In the case of failure, that seed could then be used for bisecting, eliminating the chance of falsely flagging a "bad" commit as "good" due to the randomness of input values. This change is based on #278 (for ). What's still missing: [x] Documentation: I found the section of the README mentioning the other environment variables not a suitable place. [ ] Decide whether or not it's a problem to use the same seed for all tests. I don't think so, since the same seeded will be used for all runs of a given test, and thus we'll produce different input values for each iteration. But maybe I overlooked something?
We try to shrink values recursively, i.e. when a shrunk value witnesses a failure, we'd shrink that value further. Previously, this recursion would be implemented via actual control flow recursion, i.e. a function calling itself. Since the recursion could not be unrolled by the compiler, this could result in stack overflows in some situations. Albeit such an overflow would often hint at a faulty shrinker (e.g. a shrinker yielding the original value), the stack overflow could also occur in other situations. Fixes #285.
Repository: BurntSushi/quickcheck. Description: Automated property based testing for Rust (with shrinking). Stars: 2712, Forks: 160. Primary language: Rust. Languages: Rust (99.6%), Makefile (0.3%), Vim Script (0.1%). License: Unlicense. Open PRs: 9, open issues: 19. Last activity: 3w ago. Community health: 42%. Top contributors: BurntSushi, apasel422, SeanRBurton, jhpratt, neithernut, milibopp, huonw, bluss, atouchet, sgrif and others.
When generating recursive structures, users will often use the size of the generator to bound the recursion depth. Dividing the size by the number of sub-structures appears to be a common practice. However, modifying the size of the generator passed to an implementation of would also affect the generation of sister structures if not restored after the generation of child nodes. Instead, users may choose to create a new generator instance with the target size. The new function makes use of seed from the original generator rather than entropy. In addition to bounding recursive structures, this also allows to re-create those structures based on some initial seed. This PR is based on #278 (in order to make use of ).
This type was originally motivated by observing that a class of properties will involve a pseudo-identity followed by a check for equivalence between its input and output. A generalization of would be properties which are defined by the equivalence check, only. See #280. For this class, we usually want to know _how_ those two values differ, rather than only that they do. Test-authors may thus write tests like the following in order to include those values in a failure report: This change introduces a convenience type which encapsulates the equivalence check as well as the error message generation. Using it, the above test could be written as:
In some cases, users may want to disable shrinking for a specific test. Consider, for example, some complex recursive data type. Naturally, we'd want values to be shrunk for most tests in order to isolate the specific sub-structure provoking the failure. However, due to the complexity we may end up with a shrinker with a certain complexity in itself. Hence, we may want to test our shrinker. For those specific tests, the very shrinking of input values performed by quickcheck could get in our way or cause failures on its own. Previously, the only way library users could disable shrinking in such cases was to define a wrapper type (in their own code) which forwarded but not . We suspect that the possibility of disabling shrinking for selected tests, such as in cases described above, is not too uncommon. The wrapper pattern is easy to understand and blends in well with quickcheck. Shipping one with the library will suit the described use-cases. The feature was requested in https://github.com/BurntSushi/quickcheck/issues/285#issuecomment-830269716, the wrapper pattern was suggested as a user-side solution in https://github.com/BurntSushi/quickcheck/issues/285#issuecomment-830281502.