Theories in jUnit revisited

A minor update on this stuff (see earlier post).

I've just got back from SPA2009, where there was a lot of excitement about Haskell. This seems interesting to me too, as I'm old enough to have Lisp and Prolog on the CV. One of the things I got to play with in one session was "quickcheck", a testing tool for Haskell.

Because Haskell is purely functional (for the most part), it lends itself to unit testing. Just call a function with some arguments, make some assertions about the result, no side-effects are even possible so you're done. Quickcheck allows you to constrain the process for generating sets of arguments and then you just let the system rip. So you can have, for example, one test that generates valid sets of arguments that checks for a correct result, and another that generates invalid sets that checks for appropriate errors. Much like theories in jUnit, but with the addition of automatic generation of sets of test parameters.

However, it seems clear that the Haskellites amongst us use this tool in an exploratory fashion. Hunting down that tricky to find bug that pops up now and then on live code? Not quite sure what the library in front of you does? Want to stress-test a piece of code that's going to have to cope with noisy data? For actual unit (regression) testing of real code, it's much less useful, not least because there's some randomness in the arguments which makes regression problematic.

So there it is: quickcheck for poking around, and HUnit (it had to exist) for your unit tests.