Unit Test Coverage

[Kimberley Burchett <address@hidden>]

On Thu, 15 May 2003, Jerry Jackson wrote:

> In general, the coverage question is addressed by the "try to break the
> app" approach.  When a knowledgeable developer can no longer come up
> with a scenario that breaks the app, declare victory and move on (assuming
> that we're talking about one of these "hard" domains and we can't expect
> to get information from a coverage tool).

On the subject of coverage, I'd like to mention QuickCheck, even though
it's only for haskell (not exactly a lightweight language).  I recently
had occasion to use it, and I was surprised to realize how good it is at
flushing out corner cases that I hadn't considered.

Using QuickCheck feels very different from writing unit tests, because
it's based on checking entire classes of inputs, instead of just
particular ones.  It feels like a very useful, and orthogonal, way of
testing code.  It's also extremely *lightweight* to use -- you don't have 
to think of the corner cases; it does it automatically.

The idea behind QuickCheck would work in any language, as long as there
was some way to automatically generate inputs for a function.  Since most
(all?) "lightweight" languages are dynamically typed, this might be
difficult.

The QuickCheck home page: http://www.math.chalmers.se/~rjmh/QuickCheck/

I wrote about my experience with QuickCheck here:
http://www.kimbly.com/blog/000042.html

Kimberley Burchett
http://www.kimbly.com/