Benefits of Test-Driven Development

When I have tried out test-driven development I have really liked it. It just seems easier for me to concentrate. In a typical, non-TDD situation, my thoughts try to map the use cases or requirements to my code, and it does not work very well. But writing tests kind of sits in the middle.

While writing tests, I can focus on just formalizing what needs to be done. I eventually get to the point where I can say, "If all these tests pass, then I am comfortable that the feature passes." Then, when I go to writing code, I can just focus on one test at a time. I hardly even have to think about the use cases at that point, and things just flow.

I watched a good webcast on TDD concepts and how to do some TDD in BizTalk Server (here). Some thoughts:

• Repeatable tests - I have heard many developers say, "Fixing one thing breaks things elsewhere." One of the hardest things about changing others' code or refactoring my own code is that I may be inadvertently making changes that will cause problems elsewhere. By running the tests with every build, I immediately see whether I broke anything--and I don't have to wait for testers or users to find bugs that I may have introduced. Automated testing also ensures
• Feedback - How many times have project managers asked me how far I am to completing a feature? My standard answers are 25%, 50%, or 100%. Percentages always seem to make my PMs happy. But even if I am "done" and say 100%, have I done integration testing, end-to-end use case testing? Probably not. Maybe I should say 100%*. But with TDD, the PM (or managers, or clients) could look at an auto-generated report of the most recent test results. Then they could see whatever percentage of tests for that feature have passed or failed.
• Incremental Design - KISS, DRY, The Simplest Thing That Could Possibly Work. TDD pushes me to write the minimum number of tests to make the feature work, and in turn, the least amount of code to make the tests pass. No over-design or scope creep on my part.
• Executable Documentation - If I use friendly names or description attributes for my test methods, they become a pretty good source of documentation. By scanning tests, it quickly becomes apparent what the code is supposed to do.