New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing/quick: add support for shrinking #9282
Comments
cc @arschles |
Many people understand quickcheck's utility for testing things like
I really like using other quickcheck implementations to generate a sequence of external requests and network connectivity issues that then get fed into a simulated distributed system with simulated network + clocks. When the generated input fails, the shrinker reduces it dramatically, and the (potentially quite complex) issue becomes far more understandable. Further, shrinkers automatically generate regression tests for you! Turn the failing non-deterministic sequence found by quickcheck into a regression test for deterministically watching for similar failures in the future. Does anyone NOT think that would make a great gophercon talk? :P |
I'd like to volunteer to build this, since it's been a few years since (deleted OP) proposed and volunteered. Seriously, this is so useful that sometimes I get away with only writing a single test for a low-impact interactive system, and after shrinking the testing library just tells me what I need to fix with reasonable thoroughness and clarity. What does the team think? |
Thanks for looking into this.
I think I would like to see a specific API proposal. |
The testing/quick package automatically generates test cases to be checked against a property. However, it often generates complicated values which obscure the source of test failures. Shrinking is a feature from the original QuickCheck which eases this burden by "simplifying" a failed test case as much as possible.
Evan Shaw gave a presentation on testing/quick at Gopher Summerfest, and started work on adding shrinking to the package in the stdlib. I could't find any official activity related to it, though.
I think he got a good start on the problem, but I also think the interface definition for Shrinker would be significantly simpler like this:
Also, because testing/quick generates random values for its test cases, I believe the behavior of quick.Check() can be changed to support shrinking without breaking the Go compatibility guidelines.
I can work on this feature if the Go team decides it's a good idea.
The text was updated successfully, but these errors were encountered: