Why TDD?

The need for TDD arises from the fact that there can be constant changes to the application code. This becomes more of a problem when we are using the Agile development process, as it is inherently an iterative development process.

Here are some of the advantages, which underpin the need for TDD:

• Code quality: Tests on TDD make the programmer more confident of their code. Programmers can be sure of syntactic and semantic correctness of their code.
• Evolving architecture: A purely test-driven application code gives way to an evolving architecture. This means that we do not have to predefine our architectural boundaries and the design patterns. As the application grows, so does the architecture. This results in an application that is flexible towards future changes.
• Documenting the code: These tests also document the requirements and application code. Agile purists normally regard comments inside the code as a "smell". According to them your tests should document your code.
• Avoiding over engineering: Tests that are written before the application code define and document the boundaries. Since all the boundaries are predefined in the tests, it is hard to write application code that breaches these boundaries. This, however, assumes that TDD is being followed religiously.
• Paradigm shift: When I started with TDD, I noticed that the first question I asked myself after looking at the problem was "How can I solve it?" This, however, is counterproductive. TDD forces the programmer to think about the testability of the solution before its implementation. This would result in solutions, which are testable in nature as we had used tests to derive these solutions. To understand how to test a problem would mean a better understanding of the problem and its edge cases. This in turn can result in the refinement of the requirements or the discovery of some new requirements. Now it has become impossible for me not to think about testability of the problem before the solution. Now the first question I ask myself is; "How can I test it?" This can be done by translating the requirements into tests.
• Maintainable code: I have always found it easier to work on an application that has historically been test-driven rather than on one that has not. Why? Only because when I make changes to the existing code, the existing tests make sure that I do not break any existing functionality. This results in highly maintainable code, where many programmers can collaborate simultaneously.
• Refactoring freely: Having a good test coverage over the application code allows the programmer to continuously refactor and improve the code while maintaining an idempotent nature of the application code.