Agile methods are used to actively involve customers in the development process. At regular intervals, they get the opportunity to check the progress and direction of their product with their feedback. This results in a valuable product that can be delivered quickly. With the use of test-driven development, this core concept is also transferred to technical development.
Table of contents
Test-Driven-Development (TDD) is a process model in software development that is based on testing software automatically using various test methods. Traditionally, a feature is first implemented and then tested. Test-Driven-Development reverses this process: Here, a test is first written for a new feature and then the associated logic is implemented incrementally until the test runs successfully. Then the code is revised to improve it and make it more understandable. Finally, it is integrated into the code base, where it is checked against all existing tests. Only then is the feature considered successfully implemented.
This approach can seem very unintuitive and time-consuming at first. In fact, however, it brings many advantages – especially when integrated into an agile work mode – and can even make the development process more effective in the long term.
Figure 1: Test-Driven Development describes a cyclical development process in which tests are created for code even before it is implemented.
Probably the most obvious consequence of Test-Driven Development is the higher code quality that results from the measures taken. This increase becomes measurable via various quality parameters such as the number of “code smells“ (unpleasantness in the code), bugs, etc.. These parameters are also summarized under the term “technical debt“. Also these measured values can be determined automatically and give an overview of the general condition of a software product. The goal of TDD here is to keep an eye on the technical debt and to keep it as low as possible. This results in significantly lower costs for changes and enhancements later on.
The feedback loop can be used to ensure that the code behaves correctly, but also to check that undesirable behavior does not occur. Developers are therefore not only concerned with the optimal case, but also with possible pitfalls that would otherwise only become apparent in actual user tests. The time-consuming testing phase with users can thus be shortened considerably, developers deal with the cases directly and do not first try to recreate and understand a reported error scenario. In addition, they handle bugs while the code is still “fresh“ in their minds and do not have to think their way back into it.
Code reviews are a good way to give colleagues an insight into the written code during the revision phase. On the one hand, this prevents the formation of so-called “knowledge silos“. This means that only a single team member has knowledge about a particular code component. This dependency is to be avoided. On the other hand the code quality increases, since constructive feedback is brought in. Code reviews can also be used to introduce new employees to a project or to distribute knowledge within the team. The process can also improve the division of labor and team dynamics in the long term.
If users still find further errors, existing tests support the reading of the code and thus the quick elimination of the error. New tests then immediately ensure that a specific error cannot creep in again in the future.
Customers have the advantage that the life expectancy of their software is increased and users experience fewer errors. This reduces the costs for support. However, the higher quality is only a partial goal of this process.
Figure 2: The goal of Test-Driven-Development is to sustainably reduce the Cost of Change compared to a traditional workflow.
In agile process models such as Scrum or Kanban, an iterative development cycle is depicted in contrast to traditional methods. This is designed to deliver a usable product to customers as quickly as possible and to obtain feedback as early as possible. In this way, problems can be addressed directly in the further development process and the direction can be corrected. Test-Driven-Development transfers this cyclical workflow to the technical development level. As shown in Figure 1, the cycle consists of continuously writing tests, implementing functions and revising the written code. Working in cycles selectively reduces the complexity of a task and helps maintain focus.
In agile processes, customer requirements can change again and again. Therefore, flexibility and ease of change in the code base must be taken into account as early as the development stage. This, in turn, is only possible if the code base is lean and focused, which is ensured by constant revision. High technical debt means that changes can lead to regressions, which are sometimes time-consuming and expensive to fix, or even only become apparent on the production system and thus cause additional support costs. The goal of TDD is shown in Fig. 2.
Test coverage, successful test runs and reviews can help to formulate a meaningful “Definition of Done“ in an agile environment and to verify its fulfillment objectively. A good Definition of Done is necessary to create clear expectations for the completion of a feature between the development team and the customer. It is usually not limited to the pure development time a developer needs until a feature is visible, but until it meets all mutually agreed requirements. These can be of a functional, qualitative and security nature. If there is no common understanding between the development team and the customer, functions that have actually been completed often have to be reworked. This can disrupt the workflow and ultimately lead to functions taking a very long time to implement.
Test-Driven Development builds on agile values and helps to exploit the full potential of this way of working. Initially, the cycle time in a team can increase while the developers learn to use the new methods. Over time, as new concepts become routine and experience is built up, the effort becomes negligible and pays off with a lower cost of change. The controlled increase in software quality is ultimately the only reliable method for accelerating the development process in the long term.
Agile workflows and test-driven development are both designed to obtain and respond to feedback quickly. Agile process models focus primarily on the organizational side. To ensure that this can also function smoothly from a technical point of view, Test-Driven-Development introduces the agile values at the development level. As with the implementation of the agile framework, it is essential here to adapt Test-Driven-Development to the circumstances, the team, the project context, etc., so that it is effective and brings benefits for both customers and the development team.
Software Developer
