Test-Driven De­vel­op­ment

As computer programs become in­creas­ing­ly complex, the agile methods of test-driven de­vel­op­ment (TDD) are also becoming ever more popular. For good reason: TDD helps pro­gram­mers ensure the design of their software program is well thought-out before they proceed to write the func­tion­al code. Not only does this increase the quality of the software con­sid­er­ably, but also reduces the main­te­nance costs.

Test-driven de­vel­op­ment is used in extreme pro­gram­ming, for example, which is char­ac­ter­ized by ongoing reviews, tests, design, and redesign. TDD likewise follows a de­vel­op­ment cycle and its sequence needs to be main­tained for effective im­ple­men­ta­tion.

There have been a variety of test methods that manage software quality for quite some time. At the start of software de­vel­op­ment, in­de­pen­dent testers in quality man­age­ment would examine computer programs in terms of their func­tion­al­i­ty. Back then, the actual de­vel­op­ment of software and the testing pro­ce­dures were still con­sid­ered to be separate processes. The test-first approach did not emerge until US software developer and founder of extreme pro­gram­ming Kent Beck published his work. His approach simply reversed previous practice: Instead of first writing the source code and then testing it, the de­vel­op­ment team began by writing the tests. The team then used the test cases to write and implement the best possible code.

Even though test-driven de­vel­op­ment may initially seem coun­ter­pro­duc­tive to laypeople, it certainly has its ad­van­tages and can lead to better results. While a waterfall or V model is applied in con­ven­tion­al, sub­se­quent testing, TDD processes follow a cycle. This means that test cases which often fail are defined on purpose. This is often the first step followed by writing only as much code as required to pass these tests. Sub­se­quent­ly, the com­po­nents are refac­tored. While main­tain­ing function, the source code is expanded or re­struc­tured if necessary.

Test-driven de­vel­op­ment is based on the results of test cases you define. The cyclical approach ensures that the code is only applied to the func­tion­ing system once all re­quire­ments on the software are met. This means that you refactor and retest code com­po­nents as often as necessary until the test is no longer failed. This method allows you to gradually augment the software with new functions, since you write a new piece of source code after each test is passed. For this reason, TDD is also con­sid­ered an in­cre­men­tal model of software de­vel­op­ment.

In­di­vid­ual test cases typically go through the cycle for no longer than a few seconds or minutes. This way, the results can quickly be seen in the func­tion­ing code. For efficient iteration, you’ll need a TDD tool and framework. Usually, de­vel­op­ers use a tool for build au­toma­tion like CruiseC­on­trol or Jenkins. These enable the con­tin­u­ous and faultless in­te­gra­tion of com­po­nents in the source code. JUnit, Maven, and Ant are also popular in Java de­vel­op­ment. In general, the tests are always written in the same language as the func­tion­ing code. For PHP, you can use tools like Ceedling or CMock, for example.

But how is the test method applied? The cycle which pro­gram­mers follow in test-driven de­vel­op­ment is also known as the red, green, refactor cycle. This describes the in­di­vid­ual phases that you go through for maximum ef­fi­cien­cy:

1. Red phase: In this phase, the user per­spec­tive is con­sid­ered which means that code needs to be simple. In other words, you write a test that contains com­po­nents that have not yet been im­ple­ment­ed. Therefore, you need to make a decision on the elements that are essential for a piece of code to work.
2. Green phase: Let’s assume the test fails and is marked red. You now step into the role of a pro­gram­mer who tries to find a simple solution. Most im­por­tant­ly, you only write as much code as necessary. You then integrate it into the func­tion­ing code so that the test is marked green.
3. Refac­tor­ing: In this step, the func­tion­ing code is “tidied up” and perfected in its structure. This means that you should amend and re­struc­ture it so that it becomes simple and elegant to read from a developer’s per­spec­tive. Steps involved include removing du­pli­cat­ed code, for example.

Make sure that the in­di­vid­ual ac­tiv­i­ties do not overlap, i.e. don’t write tests in Phase 2 or 3 or func­tion­ing code in Phase 1 and 3. The following video shows how test-driven de­vel­op­ment works in practice:

Test-driven de­vel­op­ment is a design strategy that guides the de­vel­op­ment process for a software program using various tests. In contrast to down­stream methods, the test cases in TDD are part of the software design from the very beginning. The tests used in TDD vary in terms of purpose and scope. The simplest test is the module test or unit test. This tests the in­di­vid­ual com­po­nents of a computer program. In­te­gra­tion and function tests are more complex. They are used to assess the interplay of various system parts and the overall func­tion­al­i­ty of a software program.

A few years ago, behavior-driven de­vel­op­ment (BDD) emerged from the TDD approach. In the case of BDD, a developer team initially focuses only on the desired behavior of the software, rather than the cor­rect­ness of the code. The advantage here is that you do not need any technical coding skills to write test cases and can, therefore, involve stake­hold­ers and quality managers in the de­vel­op­ment process. In general, BDD defines the best approach for writing tests, while TDD provides neat ar­chi­tec­ture.

The table below briefly sum­ma­rizes the ad­van­tages and dis­ad­van­tages of test-driven de­vel­op­ment:

Although you can also use the various test methods in­di­vid­u­al­ly, you can produce a higher-quality software program by combining test-driven and behavior-driven de­vel­op­ment methods. As a result, the end user will ap­pre­ci­ate the final product all the more.