TDD: should this approach be abandoned ?

Test-Driven Development (TDD) is the process of creating code that tests whether the actual project code works as expected. This software development process involves designing test scripts first, before actually programming the application. This method is often cited in good development practice as resulting in higher quality applications. However, TDD is still not widely used by developers because it requires a lot of time to create and execute tests.  Does this mean that Test Driven Development should be abandoned? Find out more about the benefits and risks of test-driven development in this article.

Test Driven Development: what does it involve?

Definition and steps of TDD

Before presenting the advantages and disadvantages of TDD, it is essential to understand what the process is all about. TDD is a development method that combines programming, unit testing and refactoring (also called continuous improvement).

More concretely, development teams will create test cases for each function in their applications, run them and, if the tests fail, modify the code until they work. How is this different from traditional and automated testing methods? The major difference is that with TDD the tests are designed and programmed before a single line of code for the functionality has been written. The test describes the expected behaviour of an interface and the interface is then developed based on the various test results.

The TDD framework is based on several steps:

• 1) Write a unit test describing only one part of the problem;

• 2) Confirm that the test has failed;

• 3) Write the minimum amount of code necessary to pass the test;

• 4) Run the test to confirm its success;

• 5) Repeat by refactoring the code and checking for regression.

A simple example of TDD

To better understand the TDD framework, let's take the example of a gym that sells memberships based on the age of the buyer. To develop this application with TDD, you start by writing a simple test:

public void test_age() { 

      int tarif = get_tarif_age(3) ; 

      assertEquals("Children under 3 years of age cannot be members of the gym", -1,tarif) ; 

}

In this example, the function get_tarif_age() returns the rate for a given age. The rule is that a 3 year old child is not allowed to take out a gym membership. The next step is to write the minimum code necessary to pass the test, which can be done in pure TDD mode:

public static int get_tarif_age(int age) { 

   return -1 ; 

}

This code passes the test, but of course does not meet the functional requirements. Another, more realistic, example of a test could be: 

public void test_trente() { 

    int tarif = get_tarif_age(30) ; 

      assertEquals(“30 year olds have a €50/month subscription”, 50, tarif) ; 

}

The developer should then add the instructions to return €50 per month if the age received as input is equal to 30 (or on age ranges) and then proceed to the next test. All other inputs and functionalities will be tested and developed according to this model.

The benefits of test-driven development 

The main advantage of TDD is that it reduces bugs and malfunctions in applications since all tests are run several times throughout the development process. This approach requires programmers to be particularly rigorous, as each failed test requires immediate correction. In addition, this approach allows for the detection of the slightest regression and the constant refactoring of the code.

The other main benefit is that the overall application is better designed, as writing the tests before development pushes the teams to think more about the expected functionality and spend more time on the design phase of the project. Test driven development is regularly associated with XP, Scrum XP and the devops approach. 

Other benefits of the TDD approach are:

• a more modular software design, with developers focusing on one feature at a time;

• code that is easier to maintain, as it is more synthetic, clean and readable;

• better documentation, as unit tests can be used as feedback to illustrate how the code should work.

The risks of test-driven development

The way TDD works reveals one of its major weaknesses: the time needed to implement it. Writing the tests in advance logically means that the project will take much longer to get going. It depends on the architecture of the application. The example provided above is simplified and most programs include dependencies or call on external data and services that may invalidate the tests.

TDD can also be costly and time consuming on projects where requirements are not clearly defined. If the expected functionality changes, the old tests become useless and the loss of time is much greater than if the developers had only designed the "real" code for the application. Similarly, any changes or modifications to existing code mean that tests must be maintained, modified and re-run several times.

Finally, the TDD methodology can be quite complex to get to grips with and requires that all developers on a project apply the framework at the risk of missing tests or leaving some unmaintained. 

The disadvantages of TDD are therefore mainly related to the nature of the projects and their framework. This is not an approach that needs to be abandoned, but should be reserved for applications where inputs and outputs are clearly defined. In these cases, the test-driven development process enables design of reliable, efficient and more easily maintainable programs. Conversely, TDD may be too difficult to implement on existing or complex applications.

Do you regularly use the TDD framework in your projects and assignments?