TEST DRIVEN DEVELOPEMENT – When to, When not to

Concept

Test Driven Development (TDD) is a lightweight programming methodology that emphasizes fast, incremental development and especially writing tests before writing code. Ideally these follow one another in cycles measured in minutes. TDD is one of the core practices of Extreme Programming (XP).

Functionality in TDD is added in very small chunks. Typically the first cycle will deal with quite simple cases. Once we have these very simple tests working, we add more functionality, a bit at a time.

It can be basically seen as a three-step approach: write test, write code, refactor.

Argument

Test Driven Development can be used as long as the specifications are clear enough to let us write tests that would the software’s compliance. From there on, we can start writing the software.

It can also be used with existing software projects, but this would not be necessarily easy. Indeed, the larger the software project, the larger will be the blocks of untested code at the core. We could just write a huge test to exercise the block of code, but again this will be time consuming, subject to fail, and is also against the TDD spirit.

A good practice would be to concentrate on using TDD with any new project code, and regularly refactoring what already exists, breaking it in smaller piece of code over a period of time.

The use and implementation of TDD also depends on the size of the project as said earlier. Indeed, because TDD emphasizes on flexibility and fast turnaround, it is mostly used in projects involving no more than a few dozen programmers.

Also before getting into the TDD process, people have to lean it. This depends upon the individual and the circumstances. Basically it is a matter of developing a new habit.
On the other hand, we might find that it's best to learn it with someone else. If you can pair off with someone experienced with TDD, this can be especially beneficial.

To conclude, some practitioners believe that TDD cannot be used in developing multi-threaded code, or where security is a key consideration. Some arguably disagree with both of these conclusions. For best results, of course, TDD relies upon good relations with the customer and well-conceived specifications.