Want better code? Get your developers testing!

The term Test-Driven Development (or TDD) has been around for a while but its full potential for software development is still not commonly being realized in most IT companies. Although in the beginning, putting it into practice might seem more hassle than it’s worth, its numerous benefits quickly become evident.

Recently, I had the opportunity to share my experience of applying TDD in Nortal’s client projects at an annual international testing conference, Nordic Testing Days. The conference is primarily aimed at software testers, but now it has been opened up to basically anyone interested in learning more about testing and contributing to a smoother software development cycle and better quality.

For those not familiar with TDD: it is a software development process that relies on the repetition of a very short development cycle. Each requirement is turned into a specific test case, and so basically, it offers a test-first programming concept.

Normally, tests are only written after completing the full implementation of the code (and the testing process is only done by testers). TDD starts with testing: the developers write the tests first and then write the code that will get all the tests to pass. In this way, they can incorporate testing as a part of the development process.

So far the most common objections around against applying TDD are that it is 1) time-consuming – TDD takes too much time to learn and it takes time to apply, and therefore, it is 2) costly and 3) critics say the testing should be done by testers and not duplicated by developers.

However, although the time and financial resources required for TDD seem higher at first, when compared to the normal approach, time has shown that projects that don’t have tests written first usually end up costing more. Not only does TDD save time on fixing bugs, it also means that it costs less to change functionality as the tests act as a safety net ensuring that any changes along the way don’t undermine the existing functionality.

TDD is not only about testing; it is a living documentation of the software development process that makes it much easier to understand the behavior and functionality of the code. It is also a refactoring safety net for any changes in the code, as it is instantly clear what works and what doesn’t, and therefore it operates like a design driver that, since it promptly shows up any errors, helps to write cleaner code faster and with fewer bugs.

To mention just three more benefits – it makes development considerably faster, as every time a change is necessary, the entire application does not need to be recompiled and redeployed; it increases confidence, as the thoroughly tested code provides insurance for developers that the code works as expected; and it helps to produce simpler designs by producing code that is easier and less expensive to maintain.

Overall TDD is not a magic wand that can fix everything independently, but is a very useful tool that simplifies the developer’s work process and ensures better quality.