|
Test Driven Development (TDD) is a design technique that drives the
development process through testing. In essence you follow three
simple steps repeatedly: - Write a test for the next bit of functionality you want to add.
- Write the functional code until the test passes.
- Refactor both new and old code to make it well structured.
You continue cycling through these three steps, one test at a
time, building up the functionality of the system. Writing the test
first, what XPE2 calls Test First Programming, provides two main
benefits. Most obviously it's a way to get
SelfTestingCode, since you can only write some functional
code in response to making a test pass. The second benefit is that
thinking about the test first forces you to think about the
interface to the code first. This focus on interface and how you use
a class helps you separate interface from implementation. The most common way that I hear to screw up TDD is neglecting
the third step. Refactoring the code to keep it clean is a key part
of the process, otherwise you just end up with a messy aggregation of
code fragments. (At least these will have tests, so it's a less
painful result than most failures of design.)
|