Test Driven Development the Pros and the Cons

Test driven development is a method of software development typically followed in teams adopting the ‘Agile’ software development model. TDD requires the tests to be written first then the functionality being coded for the tests to pass. This implies that each new line of code being written should have an already existing and failed test case for it.

The following figure represents a typical TDD workflow:

First of all, tests that need to pass are identified for the given functionality are identified and coded in the programming language or the framework of choice.

Then the code is written to make the tests written for the functionality pass.

After the code is written for tests then the tests are executed to check if the tests pass. If the tests pass then the new tests are written for new functionality in the application else the code is fixed to make the existing tests pass. This cycle is repeated over the entire application development life-cycle.

A programmer following a TDD approach is likely to refuse to write a new function/line of code until there is an existing test written for it.

By default the source code generated using the TDD methodology is more thoroughly tested and the confidence level is much higher than the model oriented development approach.

TDD ensures that the code is unit tested and the code coverage is 100%.

The chances of scope creep by the developers are also minimized as the pre written tests tend to prevent it.

Over the period of time the adoption rate of TDD has been comparatively low due to various reasons. Some of the reasons include the myths associated with TDD methodology, such as:

Scalability issues: The scalability issues may be due the tests taking a long time to run especially in large projects.

Training needs: In terms of the effort required to train the team on how to write good tests. Developing the test writing skills is an incremental process at it takes its own time to mature. It just cannot happen overnight.

Technical Challenges: There could be technical challenges as well for example writing tests in the multi-threaded environment could be very challenging and may not be the ideal approach to be taken.

Resistance to Change: every new way of working is opposed.

Religious Refactoring of the Code is essential and would be required at every milestone. In case of change of the application logic the tests need to be updated accordingly which might be a big overhead for large and complex projects.

TDD is often thought to be the complete solution for software quality and people perceive that other software testing verticals are automatically taken care of. However, the fact is that TDD may yield a perfectly unit tested code with greater conformance to the specifications, but the need of all the testing verticals is very much there. The functional regression, the performance and the load testing, and the security testing functions will always have to be there to support the over all quality of the product being developed.

So TDD has both its pros and cons, and you nee to weigh them before going TDD.