Driving Development with Tests: ATDD and TDD
Driving Development with Tests
In Extreme Programming, programmers practice Test Driven Development (TDD). They begin
developing code by writing a failing executable unit test that demonstrates the existing code
base does not currently possess some capability. Once they have a failing unit test, they then
write the production code to make the test pass. When the test is passing, they clean up the
code, refactoring out duplication, making the source code more readable, and improving the
design. TDD involves working in very small steps, one small unit-level test at a time.
Despite its name, TDD is a programming practice, not a testing technique. It happens to result
in a fully automated suite of unit tests, but those unit tests are a side effect, not the ultimate
goal. Practicing Test Driven Development is much more about setting concrete, detailed
expectations in advance, and allowing those expectations of code behavior to guide the
implementation than it is about testing.
Like TDD, Acceptance Test Driven Development (ATDD) also involves creating tests before
code, and those tests represent expectations of behavior the software should have. In ATDD,
the team creates one or more acceptance-level tests for a feature before beginning work on it.
Typically these tests are discussed and captured when the team is working with the business
to understand a story on the backlog.