Test Driven Development (TDD) which is also referred to as test-driven design is a widely-accepted methodology in the field of software development. It typically relies on repetitive unit tests which are executed on the source code being developed. In a way, this is to start with the end in mind – designing the test cases that have to be “passed” for the code under development to be found “acceptable.” The idea of TDD is to expedite the development and testing process even though the tests may not be perfect in the first iteration. With each cycle of new code development, refactoring is done for the tests and the similar tests are executed. Finally, the iterative process is run till the desired functionality starts to work as expected. Despite being an integral part of the approach adopted by many software development teams there are certain myths or misconceptions that are associated with implementing TDD. Let’s take this chance to look at some of them, and hopefully, put them to rest.

Employing TDD is a time-consuming process

TDD actually comes into its own when it comes to measuring long-term benefits. The focus of every organization’s management team is to be able to deliver the end product within the agreed timelines. Adding TDD to the picture could increase the overall time-estimates and can thus be viewed as a time-consuming process. However, implementing TDD has long term advantages, as it helps to increase the overall productivity of the developers. TDD reduces the number of defects that are detected only once the application is deployed in production. Post production, much more time is spent in investigating, isolating and fixing the issue, which could have been avoided by using TDD. Having production issues also tarnishes the image and reputation of the organization and eventually leads to an unsatisfied customer.

R Jeffries and G Melnik, writing for IEE have reported that TDD helps in decreasing production bugs by 40-80%. Of course, it can add 10-30% to the initial development time and cost but considering the factors like defect fixes, and maintenance it is justified to implement TDD for the first phase of project development. In fact, the benefits of TDD have been tested on real projects by several companies and they found that the process is enormously beneficial.

Writing test cases before the code, is not feasible

With the introduction of the Agile approach, the process of software design has moved from the waterfall model to more iterative model. It is a challenge sometimes, to convince the developers to write test cases as the design is being built, but this helps developers to consider multiple scenarios which may lead to failure situations in real time. The idea of TDD is that it paves a way for the developers to think in a way which eventually leads to better design. TDD adds efficiency in code creation as there is an immediate feedback from the unit test. Also, developing code with unit tests allows parallel development and reduced debugging and testing time.

TDD is a software design method for better design

Technically, TDD is not really a software design methodology but it does lead to better software design! By developing your code using the TDD way, it automatically leads to a better-designed code as it is not possible to create meaningful test cases for poor or low-quality code. But the application design still needs to be catered to by having a clear idea of things like data structures, design patterns, overall system architecture, feasibility, and scalability considerations.

TDD always ensures complete code coverage

The goal of every testing organization implementing TDD is to have 100% code coverage. Code coverage is useful in the context when there are well-written tests. Writing incomplete or bad tests will not help in the above situation. Ideally, code coverage should be measured on a line or snippet if the covering tests are passing. Code coverage cannot guarantee 100% sufficiency. Usually, TTD code is likely to have a near-perfect code coverage but it may possible that a perfectly covered code will not necessarily be sufficiently tested.

James Grenning, who has written a lot about TDD said, “The best TDD can do, is assure that code does what the programmer thinks it should do. That is pretty good BTW.” TDD is a proven concept and is embraced by many developers and organizations. If this is the approach that works for you then go ahead and join the legion of followers – if the objections you encounter are from among those listed above, then you know just how true they really are.