TestDrivenDevelopment
Write the test of the requirement first, then write code to make the failing test pass.
Definition
This is an XP core practice. When detailing a requirement, write the test of the requirement first (see AcceptanceTests), then write code to make the failing test pass.
Source
Discussion
Test Driven
Development has several purposes, not all of which need to be applicable. This is one of the key enabling techniques
for agility, providing automated regression tests that enable change to be made
without fear of breaking existing functionality. TDD provides the rigour to ensure all code is covered by
regression tests, because there is no mandate for writing code unless there is
a test that is failing. Additional
discipline is required to ensure no more code is written than is required to
pass the failing test. Refactoring is the
exception, where code structure may be changed without having failing tests;
the presence of tests allows us to refactor without the risk of breaking the code
undetected. In an XP environment it is recommended to write one test and make it pass before
writing the next. Less agile
environments may need to write tests in batches.
TDD can
provide tests that can act as the only written requirements for a system. If the user specifies the requirements, in
collaboration with the developer, in the form of specific criteria that the
software must meet to be acceptable, then these criteria can form a set of
acceptance tests. Note that TDD would
also have tests specified by the developers to provide ‘white box’ testing to
complement the ‘black box’ acceptance tests.
TDD can
provide examples of how the programmer intends the code to be used. This reduces the need for documentation.
Contra-Indications
Unless SimpleDesign is practiced, TDD may require many more tests than strictly necessary. Unless ConstantRefactoring is employed, writing tests one at a time or in small batches may lead design down blind alleys. The ability to refactor allows us to design simply and incrementally; without this more up-front design effort will probably be required. The value of automated regression tests is diminished if the tests take so long to run that there is an incentive not to run them frequently.
References
1. Forum hosted on Yahoo
2. Ambler essay on Agile Data site