Let He Who Has Never Compiled Untested Cast The First Stone

Tim Bray has a good post about “Test-Driven Heresy,” in which he admits failing to live up to the ideal of writing tests firsts and only writing enough code to pass a test.

I’m Catholic in my test-driven beliefs, which is to say that I am a terrible sinner, but I like to think that I can be forgiven if I just confess my lapses. They are many and varied and far out-strip my actual adherence to test-driven development. The spirit is strong, though.

Why is it so hard, even for believers, to keep things test-driven (or even test-in-the-passenger-seat-but-navigating)? Bray points out that when you’re writing prototype / spike code, it’s difficult to write tests because (a) part of prototyping is being wildly wrong in your expectations and (b) when the codebase is very small, the effort of separating concerns is relatively high.

I agree. To make sinning easier still, it is also the case that refactoring towards test-driven is difficult with large, “ball of mud” codebases (exactly the ones that would most benefit).

So there’s a “window” in which initiating test-driven development is relatively easy. Unfortunately, that window is not a very large part of a software code-base’s lifetime.


4 thoughts on “Let He Who Has Never Compiled Untested Cast The First Stone

  1. Pingback: Let He Who Has Never Compiled Untested Cast The First Stone « From Big Island (FBI)

  2. How long will that Bell curve last?
    Maybe at the death bed confession, absolution, and forgiveness?

  3. I certainly hope not. I think we have to address why “Intellectually, we know test-first is better. It’s easier, it’s faster, etc. But if that’s so, why do we not always adhere to it?” I think it’s because test-first, unless introduced in a certain “window,” can be hard to introduce into a software project. What are the implications?

Comments are closed.