The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

I am a TDD fan. I’ve been one for a long time.

But I’m not a TDD practitioner. I don’t follow the TDD methodology of writing the test first, implementation second.

Not yet.

Uncle Bob convinced me to try. Again.

Time to become a TDD developer! Time to step up my code quality.

I have said it many times, Robert Martin, Uncle Bob, is someone who has had a big influence on my career (you can find other references on this site). I usually buy all his books. His latest one, The Clean Coder, is not only a joy to read, it’s filled with great advice. It’s like reading The Pragmatic Programmers again. Who doesn’t want that?

Let’s get to the point, though. Why would I ever want to follow TDD? Isn’t that counterproductive, and… silly!

Do I want to write higher quality code? Faster? Less buggy? And get more fun out of it?

Of course!

But I’ve tried before. And reverted to old ways of doing it.

This time, I want to infect myself with it.

How? By trying harder. By making this “my way” of doing things. And by actually writing the tests first.

It’s going to take more effort than that!

Today I got an opportunity to do just that. And I am surprised how I was able to kill a few bugs. Bugs that would have “bugged” me later.

But why write the tests first?

So I develop good coverage. So I design better. So I get instant feedback. Those are 3 very good reasons. Not only that, but by first thinking about the tests, I will cover more corner cases; I will make my code testable.

Do I really need more convincing?

Not really. Benefits are clear. It’s just a matter of “doing” it.

Lastly, to give some direction and insight on how to proceed, here are the three laws of TDD as per Bob.

The Three Laws of TDD
1) You are not allowed to write any production code until you have first written a failing unit test.
2) You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
3) You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Martin, Robert C. (2011). The Clean Coder

Ready to join the TDD camp?