I am a TDD fan. But not a TDD practitioner. Uncle Bob convinced me to try again.
I have said it many times, Robert Marting, Uncle Bob, is someone who has had the biggest 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?
Why?
Because I could be writing higher quality code. Faster. Less buggy. And I will get more fun out of it.
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 actually writing the tests first.
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. These are 3 very good reasons.
Do I really need more support?
Just so we’re looking at the same thing, here are 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