Test-First Programming

Frank Sommers writes...

I find myself violating this tenet of XP very often. I do test all my code, but often only after I've already written that code. Why does this one XP rule seem so out of place to me? ...

I like to think of refactoring and testing as editing. When writing an article, most writers first create an outline, then write the content, typically in a few sittings, and without regard to mistakes, typos, sentence structure, etc. Only then does an author spend most of his time on editing, fine-tuning, and polishing the article.

I think this seems out of place when "testing" is perceived to be a testing activity rather than a design activity. Rather than not testing first, try taking on a new perception of what it means to "test" software.

The way I view test-first programming exhibits the same outline -> content -> polish flow. In my perception, the "outline" is the short list of tests I think I want to write over the next hour or so. This list of tests is just a list of names, each name being some *design* feature that needs to be developed. Each name will show up in the design.

Then the "content" is the expansion of a name on the list into code:

1. One or a few function calls or message sends.
2. One or a few assertions about what is true afterwards.
3. The other code needed to setup the calls, implement the assertions, and teardown.
4. Then when this content breaks, the test framework tells me what's wrong.
5. The rest of the content is missing... I have to write the code that implements the calls.
6. When the "test" part of the content does not break, the initial draft is complete.

This content (the calls and assertions) is design information, an expression of a design contract. I am not testing something already conceived. I am in fact conceiving of something, creating something, designing something new: an expression about a system and an assertion about what is true given that expression.

As soon as the content is drafted, immediately I begin to polish that draft, consider how it fits with the other content, and how the content itself could be better expressed through reconsidering the names and parts and assertions.

So I see test-first programming as a way of designing. It happens to be a way of testing as well, which is good because a program has to be tested in ways that an informal text does not.