COVER FEATURE Test-Driven Development: Concepts, Taxonomy, and Future Direction Test-driven development creates software in very short iterations with minimal upfront design. Poised for widespread adoption, TDD has become the focus of an increasing number of researchers and developers. David Janzen he test-driven development strategy method, a close examination of the term reveals a Simex LLC requires writing automated tests prior to more complex picture. developing functional code in small, rapid Hossein iterations. Although developers have been The test aspect Saiedian T applying TDD in various forms for several In addition to testing, TDD involves writing auto­ University decades,1 this software development strategy has mated tests of a program’s individual units. A unit of Kansas continued to gain increased attention as one of the is the smallest possible testable software component. core extreme programming practices. There is some debate about what exactly constitutes XP is an agile method that develops object-ori­ a unit in software. Even within the realm of object- ented software in very short iterations with little oriented programming, both the class and method upfront design. Although not originally given this have been suggested as the appropriate unit. name, TDD was described as an integral XP prac­ Generally, however, the method or procedure is the tice necessary for analysis, design, and testing that smallest possible testable software component. also enables design through refactoring, collective Developers frequently implement test drivers and ownership, continuous integration, and programmer function stubs to support the execution of unit tests. courage. Test execution can be either a manual or automated Along with pair programming and refactoring, process and can be performed by developers or des­ TDD has received considerable individual attention ignated testers. Automated testing involves writing since XP’s introduction. Developers have created unit tests as code and placing this code in a test har­ tools specifically to support TDD across a range of ness or framework such as JUnit. Automated unit languages, and they have written numerous books testing frameworks minimize the effort of testing, explaining how to apply TDD concepts. Re­ reducing a large number of tests to a click of a but­ searchers have begun to examine TDD’s effects on ton. In contrast, during manual test execution devel­ defect reduction and quality improvements in aca­ opers and testers must expend effort proportional demic and professional practitioner environments, to the number of tests executed. and educators have started to examine how to inte­ Traditionally, unit testing occurred after devel­ grate TDD into computer science and software opers coded the unit. This can take anywhere from engineering pedagogy. Some of these efforts have a few minutes to a few months. The unit tests might been implemented in the context of XP projects, be written by the same programmer or by a desig­ while others are independent of them. nated tester. With TDD, the programmer writes the unit tests prior to the code under test. As a result, TEST-DRIVEN DEVELOPMENT DEFINED the programmer can immediately execute the tests Although its name implies that TDD is a testing after they are written. 0018-9162/05/$20.00 © 2005 IEEE P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y September 2005 43 The driven aspect and what that program’s interface should look like Some definitions of TDD imply that it is is a radical concept for most software developers. TDD assumes primarily a testing strategy. For example, in that the software JUnit in Action (Manning Publications, The development aspect design is either 2003), Vincent Massol and Ted Husted stated Intended to aid in constructing software, TDD incomplete that is not in itself a software development methodol­ ogy or process model. It is a practice, a way of or pliable Test-driven development (TDD) is a program­ developing software to be used with other prac­ and open ming practice that instructs developers to write tices, in a particular order and frequency and in the to changes. new code only if an automated test has failed, context of a process model. TDD has emerged and to eliminate duplication. The goal of TDD within a particular set of process models. It can be is ‘clean code that works.’ applied as a microprocess within the context of many different process models. However, according to XP and TDD pioneer TDD produces a set of automated unit tests that Ward Cunningham, “Test-first coding is not a test­ provide some side effects in the development ing technique.” TDD is known by various names process. The practice assumes the automated tests including test-first programming, test-driven will not be thrown away once a design decision is design, and test-first design. The driven in test-dri­ made. Instead, the tests become a vital component ven development focuses on how TDD leads analy­ of the development process, providing quick feed­ sis, design, and programming decisions. TDD back to any changes to the system. If a change assumes that the software design is either incom­ causes a test to fail, the developer knows immedi­ plete or pliable and open to changes. In the context ately after making the change, while the test is still of XP, TDD subsumes many analysis decisions. The fresh in the developer’s mind. Among the draw­ customer should be “on-site” in XP. Test writing is backs, that developer must now maintain both the one of the first steps in deciding what the program production code and the automated tests. should do, which is essentially an analysis step. The Agile Alliance offers another definition that cap­ TDD’S HISTORICAL AND MODERN CONTEXTS tures this idea (www.agilealliance.org/programs/ Despite the lack of attention in undergraduate roadmaps/Roadmap/tdd/tdd_index.htm): curriculum and inconclusive reports of usage in industry, a wide range of software tools exist to sup­ Test-driven development (TDD) is the craft of pro­ port testing, making TDD’s emergence possible. ducing automated tests for production code, and using that process to drive design and program­ Software development methodologies ming. For every tiny bit of functionality in the pro­ A software development process or methodol­ duction code, you first develop a test that specifies ogy defines the order, control, and evaluation of the and validates what the code will do. You then pro­ basic tasks involved in creating software. Software duce exactly as much code as will enable that test process methodologies range in complexity and to pass. Then you refactor (simplify and clarify) control from largely informal to highly structured. both the production code and the test code. Developers classify these methodologies as pre­ scriptive or agile and label the specific types as To promote testing to an analysis and design step waterfall, spiral, incremental, or evolutionary. the practice of refactoring must be introduced. When an organization states that it uses a par­ Refactoring changes the structure of an existing ticular methodology, it often applies a combination body of code without changing its external behav­ of smaller, finer-grained methodologies on a pro­ ior. A test may pass, but the code may be inflexible ject scale instead. For example, an organization or overly complex. By refactoring the code, the test might apply an incremental development model, should still pass but the code will be improved. building small, cumulative slices of a project’s fea­ Understanding that TDD is more about analysis tures. In each increment, the developers could apply and design than it is about testing is one of the most a waterfall or linear method of determining require­ challenging conceptual shifts for new adopters of ments, designing a solution, coding, testing, and the practice. Program testing has traditionally then integrating. Depending on the size of the incre­ assumed the existence of a program. The TDD idea ments and the waterfall’s time frame, the process that a test can be written before the program or that could be labeled differently, with potentially very test can aid in deciding what program code to write different results in terms of quality and developer 44 Computer satisfaction. If we break a software project into N can vary widely. Some testing can be con­ increments where Ii represents each increment, then ducted early—concurrent with other coding The order the equation ΣN I can represent the entire project. activities. Test-driven development reorders i = 1 i in which If N is reasonably large, we can label this as an these steps to an advantage. By placing fine- incremental project. However, if N ≤ 2, we would grained unit tests before just enough code to construction label this as a waterfall project. satisfy that test, TDD can affect many aspects tasks occur If the increments require modifying a significant of a software development methodology. influences a amount of overlapping software, we can say that project’s label our methodology is more iterative in nature. TDD’s historical context and its quality. Specifically, for project P consisting of code C and Test-driven development has emerged in ΣN iterations I= i = 1Ii, if Ci is the code affected by iter­ conjunction with the rise of agile process ∩ ation Ii, and if project P is iterative, then Ci Ci + 1 models. Both have roots in the iterative, incre­ ≠ Θ for most i such that 1 < i < N. mental, and evolutionary process models used as Similarly, with incremental and waterfall ap­ early as the 1950s. In addition, tools have evolved proaches, we expect a formal artifact, such as a spec­ to play a significant role in supporting TDD.