Test First Development

This is my attempt at sharing some of my personal reasoning around the topic of test-first development.

Let me first sum up my thoughts in one shot:

At the class level, form and function are significantly more important than implementation.

Test-first development forces me to focus on the usage and external structure of the class before allowing me to create an implementation.  Within the context of a specific behavior or piece of functionality, there are an infinite number of implementations which will work.  Given the infinite number of ways to implement the piece of functionality as a class, it’s the class’ form that is the key differentiator.  Specifically, each form exhibits a unique set of qualities.  It’s by these qualities that each implementation can be judged.

Test-first development (as it was intended) forces me to focus on selecting the highest quality form from all designs that will meet the functional requirements.  Implementation is easy.  Design is tricky.  I choose to let that which is most important drive my development process.

On the contrary, if the structure of the classes in your application are accidentally created as a side effect of their implementation, the system’s nonfunctional properties, such as maintainability, will also be accidentally affected.  This is because the external structure of your classes are the knobs for such nonfunctional qualities as maintainability, modifiability, and testability.

Given the importance of these nonfunctional properties, this is to be avoided at all costs.  Failure to meet nonfunctional requirements is the primary technical cause of catastrophic project and/or application failure.

Test-first development is a risk mitigation activity for key nonfunctional system properties and a defect-prevention process.

This ties heavily into my knowledge of system and class design–issues such as coupling and modularity.  By preselecting the form and use of the classes in my design, it forces me to think up front about the nonfunctional knobs of this cog in my system–knobs such as coupling, testability, maintainability, and modifiability.

By preselecting the structure and functionality of the class, I constrain the implementation.

Gold-plated code is a bit of an epidemic in the software development industry.  By constraining the implementation with form and usage, I become focused on implementing exactly what’s needed–nothing more.

Test-first development is neither a panacea nor a silver bullet.

It doesn’t guarantee I will select the best design.  It doesn’t even mean my selected design is implementable.  But if and when I recognize either case, I can quickly throw away the old design and start fresh. 

Or at least that’s a side effect of having a maintainable, modifiable system.

And lastly..

It’s about having a tight, automated feedback loop on the health of the implementation.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to Test First Development

  1. Sharon says:

    Nicely written. This is a great articulation of ideas that I’ve held intuitively but couldn’t explain to non-developers. (“TDD is about reducing defects, right?” Er… no.) Thanks for providing the words to explain the ideas.

  2. I’m curious, was the intentional use of “Test-first Development” instead of the widely known term TDD (Test-Driven Development) — which your observations apply to just as equally — a subtle indicator of your dislike of TDD “proper” as it is portrayed by its evangelists? Or am I just reading too much “between the lines”? :-)

  3. Evan says:


    Yes and no. I wanted to ditch the negative connotation around the TDD name and be slightly more expressive in terms of what I actually meant (“test first”).

    I’ll be the first to tell you that I’m neither a zealot nor an evangelist though. I mainly tried to capture the reasons that I personally want to write my tests first. If one of my readers doesn’t, I pass no judgement. :-)

  4. EricTN says:

    Evan, ..and your next screen cast will be **when**?? It’s been a long time and you have this Address Book app just waiting to be Test-First-ed into a working application! We’re waiting!

  5. I believe there is indeed great value in Test-First design, just as there is great value in SOLID principle design, Design Patterns, etc. My take is to use the design method(s) that fits the context(s) best, i.e., no Silver Bullet. GIGO (garbage in – garbage out).

    BTW, what do you mean by “Negative connotation around the TDD name”?

  6. Evan says:


    It’s on the todo list. I’m not sure when exactly I’ll be able to get to it. Hopefully soon. :-)


    Sorry for the delayed response. The most recent alt.net conf killed my schedule.

    As for the negative connotation, I find that some people tend to tune out as soon as they see/hear “TDD”. Their eyes glaze over and roll backwards. I was just trying to switch up the lingo a bit and be more expressive. :-)

  7. Okay, when I see “connotation”, I think of the definition “meaning that a word suggests or implies”, so I was confused. Thanks for the clarification.

  8. EricTN says:

    >> … you have this Address Book app just waiting to be Test-First-ed into a working application!

    >> …It’s on the todo list. I’m not sure when exactly I’ll be able to get to it. Hopefully soon. :-)

    That’s good. I know that Rob Conery has been doing some screencasts around this, but for me personally, it’s just a style thing. I prefer your ReSharper / HotKeys / rapid-app-dev approach. It’s the first time I’ve felt like maybe this stuff could work for me and I too can leave the crowd whose eyes glaze over upon mention of TDD. I’m also curious about the consistant usage of Interfaces. It would be great, if along the way, you could show the “wins” one gets from that approach. Thanks.