Test Driven Development

Test Driven Development (TDD) is a development and design paradigm for software in which testing of program components is used to guide the entire software development process. Test Driven Development is a design strategy that prioritizes testing prior to the creation of source code and prioritizes testing with reference to processes. The goal is to significantly increase the quality of the software and to reduce maintenance costs afterwards. TDD is mostly used in agile methods and especially in extreme programming. Other names for TDD include test-driven software development, test-driven programming, or test first design.

General Information

Developer Testing was already present in the early days of software development. While independent testers were supposed to test software solutions, developers were writing the actual code. Development and testing was usually decoupled. Only when Kent Beck increasingly emphasized testing in his remarks on extreme programming did the test first approach become known to a wider audience. For example, Beck and his colleagues said that they usually wrote the test first, and the source code was written and implemented after the test cases. Due to the progressive development towards agile methods, the test-first approach has also found its way into other programming paradigms and is nowadays sometimes regarded as a separate design strategy.

In contrast to the downstream testing, which is used in conventional paradigms such as the waterfall model, the test cases in the TDD are the starting point for the iterative, repetitive procedure: First of all, test cases are determined and implemented. These tests often fail. Subsequently, as much code is written as is necessary to pass the test. These code components are then re-factorized, meaning that the source code is successively extended or restructured while retaining functions. This is done cyclically until all software requirements are met, and the code can be transferred to the production system.

Operating principle

Test Driven Development runs incrementally: The software is expanded step by step after the first test cases have been written. At each step, the software is enriched with some minimal functions and tested again. Every faulty test results in the writing of source code; every passed test extends the functional scope or ensures the functionality of the software. Individual test cases, also called unit tests, usually take only a short time – the progress in software development is immediately visible.

Some developers write a line of code for testing and then a line of code for the release candidate. This breaking down to small components of the software leads to a cycle that structures the daily processes. This approach is exemplified in the three laws of Test Driven Development:

• Design a test before writing code for the production system.
• Write only as much code for the test as you need for failing the test (or for failed compilation)
• Write only as much code as is sufficient for the current test case and its existence.

Developers who follow these rules may use cycles that are no longer than 30 seconds long. The next step is a cycle that is based on minutes and is also known as a red-green refactor.

• Write test: Test fails and is highlighted in red.
• Writing production code and integrating it into the production system: Test passed and highlighted in green.
• Refactoring: The code is extended, supplemented and restructured step by step. Corresponding test cases and the corresponding code components are written. They run through the cycle again until the software is simple, elegant and understandable from a developer's point of view. Any untested line of code can lead to problems with refactoring, since it is primarily about the structure of the code and not the functionality of the software, which is guaranteed by the test-first approach.

In addition, there are other cycles that relate to the evolution of the development process. The so-called Specific Generic Cycle and the Primary Cycle should be mentioned here. The first cycle should ensure that the individual modules together achieve the goal of the software. The second cycle makes the limits clear that are imposed by the architecture and the previously determined rules. The goal here is a clear system architecture and the interaction of all modules and components.

Advantages / Disadvantages

The Test Driven Development approach has several advantages over conventional software development methods.

• The result of the TDD is high-quality software.
• TDD provides software that is less maintenance-intensive and more error-prone.
• Fault analysis and possible maintenance work is simpler and faster.
• Both the code and the system architecture are clearly structured and understandable.
• Redundancies and unnecessary code components are effectively avoided.

Significance for programming

In the context of agile methods in software development, test-driven development is a general design approach rather than a testing scenario. The fact that testing is carried out first, or that test cases are written, means that testing is the driving force behind this paradigm. Some developers would not write a line of source code until they have a test case for the line of code. This not only reduces the size of the code, but also ensures the effectiveness of the entire project - including shorter publishing cycles. The tests ensure that the goals of the software and its functionality are focused on. It's also easier to add more features and extend the software, even for developers who haven't been involved in the project. Although the test-driven programming may require developers with very high expertise and a lot of experience, the results speak for themselves - maintenance-free software is not a cost factor that could come into play after the release. Also, the approach provides one-way-free software that is often used by the end user because it does not contain any errors.

Web Links

• Definition Test Driven Development
• Definition Test Driven Development
• Introduction to Test Driven Development (TDD)]