With agile development methods, teams can develop more and more efficiently and economically. Agile methods also include test-driven development. Development is not tested, development is created by testing.
Test-driven development involves testing and analysis even before the first line of code has been written.
In the classical linear understanding of software engineering, the place of a test is relatively clear: a software, a system or individual components are developed and then tested.
However, test-driven development (TDD, or Test first development) reverses this process.
First, the tests are developed and written, the individual test cases are then used to write the best possible source code. In agile software development, this can not only speed up processes, but also provides a high-quality and low-maintenance code comparatively quickly.
Test First – Kent Beck’s Approach to Extreme Programming
Test-driven development is still subject to the approaches that the American developer Kent Beck founded with Extreme programming. First, a test is developed that is designed to check a single functionality. Ideally, a very simple example is taken at the beginning, with existing code, errors can also be used.
The first tests in this approach fail and are marked as red. The code is then adapted to pass the test, so that the test that has now passed is marked with green. The goal of customization is to customize the code as little as possible and as elegantly as possible.
Once a test has been passed and a behavior passes a given test, the code goes into refactoring (the third phase of Extreme Programming). In this step, code is further optimized, redundancies are removed, abstractions are used. Also in refactoring, the code goes through the test passed at the beginning with each change. This ensures that the test continues to be passed even after changes. Logically, every change is therefore considered by the tests, which means that the development is test-driven.
With further tests, which test the corresponding functionality of the unit, the code is then further optimized. A unit is considered completed when the developers no longer want to / can no longer improve the code, all tests are passed and no further meaningful tests can be carried out.
The tests for the unit are used again when the code is rewritten in the course of updates or adjustments. Although new tests can be added, the code must pass the old tests again and again, unless certain functionalities are declared obsolete.
This entire process is called the test-driven design cycle.
The importance of refactoring in test-driven design
The red failure and green passing are not the only core elements of test-driven development, in fact refactoring is of crucial importance. Cleaning up the code not only has the purpose of producing a code that is as easy to use, lean and low-maintenance as possible, but also reduces potential sources of error.
If developers write too much productive code, the risk increases that the existing tests of a unit do not cover the entire unit. So TDD also helps to advance the functionality of the code with as little code as possible, which results in less error potential.
What distinguishes test-driven development from other test methods
Many testing strategies differ in the way you test a software. In test-driven development, however, it is not so much the type of test that is played with, but the placement of the test process. Therefore, test-driven development is not considered as a different test method, but as a design principle. Writing and designing the test even before code is written has a unique advantage in agile development: You can recognize at a very early stage whether code can be used.
The advantages and disadvantages of test-driven development
The error is the norm in the first phase of test-driven development. Other tests work with the assumption that the code would pass them in the first attempt – TDD, on the other hand, deliberately makes the code fail. The error can be considered as something positive here, since it will be eliminated in the following.
Because Test Driven Design is a design philosophy and works fundamentally differently from other test strategies, an almost finished code is not tested first. The tests work from the micro to the macro level of the code and thus test every single line of code. Other design schools make interventions in the code necessary only when errors occur.
TDD starts with the error and optimizes the code from there. However, such deep interventions in the working methods of development teams cannot be compensated for by additional effort alone. Agile working is a fundamentally different method that cannot be easily implemented by every team.
Test-driven development can lead to delays and slower work in teams that are not used to this way of working. TDD is often completely unsuitable for legacy code. However, developers working with Test Driven Development have a secure and reliable overview of every single line of code – even before the first one has been written.
