The TDD Test

I have had some experience with co-workers who were doing TDD incorrectly.

The benefits of TDD is that it puts pressure on the developer to use employ several of the SOLID principles, to design for testability, high cohesion, low coupling, and the immediate elimination of technical debt by refactoring before checking in.

In order to underscore the TDD value proposition, I have found that adding one simple little step to the TDD process helps educate developers on how to do TDD correctly.

If the developer is doing TDD correctly, then the additional step won't devalue the process.

I call this The TDD Test. It tests the TDD process.

1. add a test
2. run the test - it should fail
3. write the code
4. run the test - it should pass
5. refactor the code - eliminate newly incurred technical debt
6. run the test - it should pass
7. check-in
8. delete the test
9. check-in

Sure, this loses the residual value of the test. But keep in mind that 99% of the value proposition of TDD is how it guides design-in-the-small.

(The residual value of the test can be recovered from source control. Which is why step 7 is before step 8.)

The TDD Test does not have to done in perpetuity. Just until everyone understands how TDD works.

James Coplien

At the extreme end of the unit testing spectrum is James Coplien. In his “Why Most Unit Testing is Waste” essay, he advocates keeping tests for up to a year, and then getting rid of them.

I do not share Coplien’s opinion, however he makes an interesting case. Depending on your software, what he advocates may be applicable to your situation. I do not believe his advice is applicable in the kinds of software I create.

Coplien is using waste in the sense of Lean’s Muda. He is not using it in the sense of “testing is a waste of time”.

I mention Coplien’s article because The TDD Test was inspired by his paper. The TDD Test just changes his “...up to a year...” part into “...up to a minute...”.