Take the TDD pill, it’s good for you.
I’ve been a strong advocate for TDD for a bit over a year now. It’s the thing that I would suggest to anyone who cares about improving their software development and ask me about it. Now, the benefits of TDD are well-known, yet I find many people are still skeptic about taking the TDD pill. Here is my take based on my own experience with the technique, no fluff.
Testing discipline
We, developers, enjoy writing code but not so much of testing them. Now we all know that testing is good and we shouldn’t leave it all to the QA, but it’s another story to keep the discipline to do it. I find that if a developer leaves testing to later in development, he’ll end up either forget or not having enough time to do it. Since I started doing TDD, the minimum test coverage of my code’s gone up quite a lot (about 70% on a good day).
Enforce better design
With TDD, I have to think about how to test the code before thinking about the code itself. And to be able to unit test my code, I need to have a modular design. I also need interface based design. So I have to follow a good coding practice in order to effectively design my test. Many TDD followers would say that you’re already done designing your code when you are working on your test. I can’t agree more.
Peace of mind
“Any line of code is guilty until proven otherwise“. How confident are you on your code? Are you sure that your code does what it’s supposed to do? I find myself more confident in my code and it really helps me sleep much better at night.
“Whack-a-mole” proof
Whack-a-mole scenario describes the butterfly effect in software breakage. A break or a change in any line of code can trickles and bring down the entire system. When this happens, developers usually go after and do a clean-up op on the breakage as it is. But it can get worse when the act of fixing the breakage changes the behaviors of the code and introduces more breakages elsewhere in the system.
To prevent this disaster, you need a complete code testing coverage. This testing coverage will serve as guideline. When someone changes a line of code or check in new code, you can run this entire test suite again. If all the test cases pass, you can be sure that it’s still functioning as it should. More on this in Continuous Integration
Keeping up the morale
Developing test system, one test at a time give quick win goals and direction to work on. TDD serves as a self checking system that I’m on the right path of developing working component. There’s also a sense of getting something done by the end of the day as well.
These points are based on my own experience. So, believe me, take the TDD pill it’s good for you. ![]()
Teera on August 12th 2008 in Software Development, .NET, Personal

























