Why TDD?

A lot has been said about TDD over the years, from both a positive and negative perspective. While I’m not the most proficient practitioner, I still wanted to share some thoughts on it, as it’s immeasurably changed how I write code.

I can still write code without TDD, code that works, code that performs, code that does what it’s meant to do. Sure. I’m sure you can and do too. However, the quality of that code often leaves some things to be desired.

Specifically:

1. It’s pretty hard to change, later, should that be required
2. Even early in development, it’s becoming hard to maintain
3. It’s usually pretty hard (sometimes impossible) to test

In these times, my main thought is mostly:

How can I get this to work?

When I’ve achieved that, I move on to the next task. From experience, that’s a low benchmark to hit, and one that, for the reasons listed above, sets me up for pain later.

Contrast this with writing code using TDD. When I work that way, I’m constantly asking myself:

How can I get this to work and be testable?

If I can’t test it, I don’t write it in a given way. Because, if I can’t test it, after the fact, at any given time, when anything else about the code changes, how can I be consistently confident that the code works as expected?

I can’t.

So, while the mechanics of TDD are the Red, Green, Refactor cycle, that’s not what I focus on. What I focus on is how can I be confident that the code works, and continues to work over time. Confidence. Peace of mind. Reliability. I’m building something that works.

What about you? Do you use TDD? What impact has it had on your development?

Matthew

P.S. A big thank you to Tom Oram for being a sagely TDD mentor for me over the years.