Test-Driven Development

Test-Driven Development, or TDD, is probably the most revolutionary programming technique after object-oriented programming. Most of those who have tried TDD are so enthusiastic about it that they do not want to return to the old methods.

Better Design, Higher Quality Software Code

In TDD you begin by designing a test for a small part of the functionality of the software. The writing of the code that implements the functionality defined in the test is started only after this initial test. A TDD process results in a clear and purposeful software code. TDD is particularly useful when you create code that contains demanding logic.

The tests serve as a formal definition of the functionality to be implemented. The tests that are passed ensure that the implementation meets the requirements described by the tests.

TDD improves the quality of the software code in many ways. For instance, a good unit test is used to test one small part of the functionality. To make this work, the system components must be separated from each other. The resulting clear module division and use of services via interfaces help the developers to make better designs.

When using TDD a set of thousands of unit tests is created in the project. This can be automatically run. The test set of a module being developed is continuously run. Thus, errors are immediately found and can easily be located and fixed.

The importance of the comprehensive test set created as a result of TDD can best be seen if you have to change the code for one reason or another. If, for instance, you want to improve the performance of the system by optimization, you can run the tests to make sure that everything still works as it should. The test set also functions as an always up-to-date documentation of the details of the implementation.

Better designed, high-quality code and unit tests that function as a safety net reduce the costs of software particularly at the maintenance stage.

Test-Driven Development and Continuous Integration

Traditionally, programmers may work on their own module for days or even weeks, and this makes integrating changes demanding, laborious and frustrating. The basic idea of continuous integration is that the changes are frequently integrated into the existing system (at least daily) and this integration is followed by the automatic building of the system. The safety network provided by the unit tests enables the addition of functionality in small parts reliably and quickly, resulting in only a small amount of integration problems that are easy to fix.

TDD Compared with Traditional Programming

Writing unit tests takes considerable time but it is time well spent. The time required in writing them is recovered to a large extent as the project proceeds when making changes and particularly when finding errors. In addition, error correction is considerably easier compared with traditional methods.

We have noticed that systems implemented using TDD contain far less programming errors than corresponding projects completed using traditional methods. A few years ago two projects were carried out at Reaktor, one with TDD and the other without it. The error data of the TDD project contained less than one tenth of the number of bugs compared with the error data of the other project.

Jakub Järvenpää, Software Architect

Jakub is highly experienced in efficient development methods. During his career at Reaktor, Jakub has shown in numerous projects how it is possible to help whole teams develop their working methods through his own example.