Test-driven development was introduced as part of a larger software design paradigm known as Extreme Programming (XP), which is part of the Agile software development methodology.
Steps of the test-driven development approach
Before any new code is written, the programmer must first create a failing unit test. Then, the programmer -- or pair, or mob -- creates just enough code to satisfy that requirement. Once the test is passing, the programmer may refactor the design, making improvements without changing the behavior.
While TDD focuses on the programmer interactions at the unit level, there are other popular methods, such as acceptance-test-driven development (ATDD) or behavior-driven development (BDD), which focus on tests that can be understood by customers.
These methods involve creating concrete examples as tests in collaboration between the technical staff and customer before the code is created, and then running the tests after the code is created to demonstrate the code is implemented. Having the tests known upfront improves first-time quality. ATDD and BDD require developers, testers and the business side to collaborate to imagine and discuss the software and its implications before the code is created.
Advantages of TDD
Test-driven development can produce applications of high quality in less time than is possible with older methods. Proper implementation of TDD requires the developers and testers to accurately anticipate how the application and its features will be used in the real world.
TDD creates a regression-test suite as a side effect that can minimize human manual testing, while finding problems earlier, leading to quicker fixes. The methodical nature of TDD ensures much higher coverage and first-time quality than classic phased code > test > fix > retest cycles. Because tests are conducted from the very beginning of the design cycle, time and money spent in debugging at later stages is minimized.
Disadvantages of TDD
TDD requires considerable skill to be successful, especially at the unit level. Many legacy systems are simply not created with unit testing in mind, making isolation of components in order to test impossible.
Further, many programmers lack the skills to isolate and create clean code. Everyone on the team needs to create and maintain the unit tests, or else they will quickly get out of date. And an organization looking at TDD will need to invest time -- to slow down a bit now in order to go faster later.
Finally, as with any method, the final results of TDD are only as good as the tests that have been used, the thoroughness with which they have been done and the extent to which they mimic conditions encountered by users of the final product.