Is pure TDD practical?

 

As a software developer I have always considered unit testing an important asset to programming. Most developers who do unit testing will naturally develop their own style and technique for writing tests. However many have started to embrace a new paradigm called Test Driven Development (TDD).

TDD mandates that the unit test must be written before the actual implementation of the code you are testing. I like this idea in principle, but I argue that it might not always be practical. Instead I practice what I call ATDD – Almost Test Driven Development. The difference is that I implement my code before writing the unit test, but I always envision what the test will look like before writing any code. When creating the test, I may also debug into my new code to capture output that I can use in the Assert statement of my test. This clearly violates the TDD paradigm since I already have an implementation to test. However, I feel this is more practical since it may save me a lot of typing if the result value of my code is complex and hard to produce manually. This is especially true if the output is a long complex string / xml. It is of course very important to be very careful when manually inspecting the result of the method.

Another problem I have with the pure TDD approach is compilation overhead. In large .Net solutions it is not always practical to compile and re-run your tests for every little change you make to a method while it is being created. I therefore believe the most practical approach is to implement your code first, but do so with the unit test in mind.

Tags: TDD, Test Driven Development