A Test-Driven Development Manifesto

I have been asked to codify my beliefs and practices when using the Test-Driven Development methodology. One of the things that I like about this methodology is that it is fairly easy to describe.
I believe that to practice Test-Driven Development is to do the following things in the following order:
1. Transform requirements for your task into unit tests.
2. Verify that all of these new tests fail (since none of the requirements have been met yet).
3. Start designing my solution.
4. As I add functionality that wasn’t described in step 1, I will add unit tests first.
5. I am done with my task when all of my unit tests pass.
6. Maintenance: Whenever a defect is logged against my code, start by reproducing it with a unit test. The defect is fixed when the unit test passes! (this also ensures that we don’t re-introduce the same defect later.
Ideally, all execution paths in my code will be covered by a unit test. Again, this is a huge win for maintenance since I can write new features and refactor existing code without being afraid of breaking any existing features or defects (refactoring is complete and successful when all of my unit tests pass).

Statement of Purpose

I believe that in order to be a good software developer (or technical resource in general), one must be able to communicate in an easily understood manner. Unfortunately, dental work is usually preferable to writing for most developers (myself included).
I believe that the solution to this problem is simple: practice. I think that writing (indeed all communication) is a kind of intellectual muscle that needs to be excercised regularly if it is to be relied upon.

It is my goal to use this blog as a sort of arena in which to practice my technical writing (and get a few things off my chest at the same time).

Because I am a professional software developer and sometimes architect, expect to see most of my articles written around software development practices.