Closed cstorey closed 8 years ago
FWIW, the tests seem to be failing thanks to some oddities with how travis deploy the rust compiler. They pass on both nightly and stable locally.
Thanks! Is there any chance we can add a regression test for this? I've found it pretty tricky in general to test this stuff, but one way might be to take your test and run it with quicktest
(which returns a Result<usize, TestResult>
, unlike the typically more convenient quickcheck
). You'd then have to inspect the Vec<String>
arguments: http://burntsushi.net/rustdoc/src/quickcheck/tester.rs.html#130-134
If not, no worries and I'll get this merged today.
I'll more than likely have some time to do that tomorrow, then.
Okay, I've added the test; but I'll happily admit that it is basically a hack; hypothetically, I could parameterize the TestResult
on the argument-tuple type, but that'd be a significant change for what seems like comparatively little value.
Thanks,
@cstorey Awesome, that looks like exactly what I had in mind! Thank you! :-)
This PR is in 0.2.26
on crates.io.
Re: tickets #126 and #127.
This ensures that we try to recursively shrink a failing case, in order to find the smallest instance. Repeating myself, this means that the test case:
Will fail with
[quickcheck] TEST FAILED. Arguments: ([true, true])
, rather than something like[quickcheck] TEST FAILED. Arguments: ([false, false, false, true, true, true, false, true, true, ...])
. This was mostly just adapting the logic used previously to the new macro.I'd welcome any feedback on how you think it might be improved.
Thanks,