Test Driven Knowledge Management

James Carr had a nice piece recently on Test Driven Development (TDD) Anti-Patterns in which he begins to build a catalog of anti-patterns to be on the lookout for. The underlying principles embodied in these anti-patterns apply to unit testing of many sorts, and two of the entries in James' catalog speak to an important purpose of automated unit testing that is sometimes downplayed.

The Enumerator
A unit test with each test case method name is only an enumeration, i.e. test1, test2, test3. As a result, the intention of the test case is unclear, and the only way to be sure is to read the test case code and pray for clarity.

The One
A combination of several patterns, particularly TheFreeRide and TheGiant, a unit test that contains only one test method which tests the entire set of functionality an object has. A common indicator is that the test method is often the same as the unit test name, and contains multiple lines of setup and assertions.

These two anti-patterns hint at the value of automated unit tests as documentation. Well-structured unit tests establish an impenetrable border around a module and serve many purposes, including documentation of the anticipated behavior in a very tangible manner. During development, this serves as a specification of sorts. Later, during product maintenance and support, these unit tests continue to serve an important role in the Knowledge Management capability, providing ultimately meaningful and contextually relevant documentation of the expected function of the module. What's more, this documentation is virtually guaranteed to be current and accurate.

Of course, the role of unit tests as documentation is secondary to the more direct quality implications, but it's always good when we can get more bang for our buck.