The claim is true: QuickCheck is surprisingly more effective at finding problems (and documenting expected behavior) than unit tests. When I first tried it, no

The claim is true: QuickCheck is surprisingly more effective at finding problems (and documenting expected behavior) than unit tests. When I first tried it, not long after the QuickCheck paper came out at ICFP 2000, it found problems that I never would have thought to test for. [1] (That's why I end up writing something like QuickCheck when I code in environments that don't already have one. [2] It's worth it.) The key to its effectiveness is that it doesn't suffer from limited human imagination. When I write test cases by hand, it's up to me to think of all the things that could go wrong and write test cases for them. But, being human, I have blind spots. Even when I try to be systematic about detecting edge cases and writing tests for them, I miss some. But when QuickCheck-like tools write the test cases for me, they can dream up corner cases like you wouldn't believe. And, even better, when I use QuickCheck, my test code doesn't end up looking like an enumeration of corner cases. Instead, it becomes clear, concise, and formal documentation. (For a good example of QuickCheck properties as documentation, see [3].) I just specify the intended general properties of my code, and QuickCheck generates the messy test cases behind the scenes, where they don't become visible noise. [1] http://blog.moertel.com/pages/seven-lessons-from-the-icfp-programming-contest http://blog.moertel.com/pages/seven-lessons-from-the-icfp-pr... [2] http://search.cpan.org/dist/Test-LectroTest/lib/Test/LectroTest/Tutorial.pod http://search.cpan.org/dist/Test-LectroTest/lib/Test/LectroT... [3] http://haskell.org/ghc/docs/latest/html/libraries/base/Text-ParserCombinators-ReadP.html#g:5 http://haskell.org/ghc/docs/latest/html/libraries/base/Text-...