I have written two blog posts about the benefits of Test Driven Development. At first, I had concerns about drawbacks to practicing TDD. I believe that many people share those same concerns too. Over time I discovered that those drawbacks are either negligible, or acceptable given the benefits of the practice. I will dive into some of those concerns as I recall my first attempts at understanding TDD.
Of the three rules of TDD, the first one says you do not code until you write a failing unit test. This sounded strange, since it sounded like it is more work to write the both tests code. I have come to understand it as this: If you understand your problem well enough, you should be able to write tests that confirm that your code solves the problem. If you are not able to define and write tests, then you either do not understand your problem well enough, or whatever you are working on is not the kind of problem that can be tested via TDD (which is a much rarer case). Now this is important, because if I do not understand the problem and the solution well enough, I may deliver the wrong solution and I will have to waste time to rework my solution.For this reason, approaching the problem by focusing on what solves the problem is a strong benefit of TDD. Writing the tests first combines with the third rule of TDD to solve another issue too.
For the third rule of TDD, only write enough production code to pass the currently failing test. This rule forces me to only write what is needed to solve the current problem. Although not explicit, this step in TDD also asks that I pass the currently failing test as quickly and minimally as possible. Do not think ahead to future problems and solutions. This is important because any thought to future problems and solutions is speculative. The conditions may change by the time I get to the future problem, and I may need to rework my code to accommodate the correct solution. Under these rules, the amount of production code is generally smaller than a solution I would have come up without test driven development. Yes, I may have written more code than before because of the tests. But the tests added the confidence to deliver my code and to test for broken functionality when I make changes. Without the tests, I would have to test my code manually by hand, and I can never have 100% confidence that my code works consistently. Practicing TDD does mean that I write more code and that takes some more time. But the benefits mentioned before do outweigh the costs, enough to make TDD a worthwhile practice.
I hope that through these blogs, my experiences with TDD provide enough information for others to determine if it applies to them. I have spoken to the benefits and drawbacks I encountered on the path of learning to use TDD. I would also like to emphasize that TDD is a tool. As such, a tool must be used correctly and used at the write time and place. I hope that everyone can give TDD a chance and see for themselves how useful a tool it can be.