How many of you are Extreme Programmers?

Duncan Booth duncan at
Thu Apr 17 16:06:04 CEST 2003

Robin Becker <robin at> wrote in 
news:XiCE$IAjFmn+Ew43 at

> I get the impression that XP is intended as a design none/test all
> process where the code some grows organically into the requirement
> through bursts of coding and testing. It even seems as though the
> testing is primary.

XP ranks design very highly. Its just that it recognises that coding is an 
aspect of design. 'Big design up front' thinks design is something you do 
once before you start coding, XP thinks that design is continuous 
throughout the process.

> Can XP be reduced to choosing candidates from the pool of programs that
> best satisfy a set of tests? If so experience from GP suggests that the
> tests require care to avoid common pitfalls. As an example a program
> might complete all the tests perfectly, but fail on all other instances
> of data (this commonly happens to overspecialised solutions).

What makes test driven development so powerful is that you write the 
specification while thinking about WHAT the code has to achieve. If you 
write the test after the code you are inevitably thinking about HOW the 
code achieves its results. Writing the test first means your tests relate 
to the specification rather than the implementation.

You are correct to some extent, if the programmer didn't think of 
particular cases when writing the tests, then XP almost demands that the 
code doesn't support those cases. In particular, deliberately writing code 
that fails on all data other than the tested data is a common way to do 
TDD: Write a test, make sure it fails for the expected reason, then write 
minimal code to make it pass (which might involve hardwiring the result), 
make sure the test passes, refactor all the while making sure all tests 
still pass.

The refactoring stage is the one that (hopefully) renders the code as short 
and clean as possible, which includes removing special case results and 
making the code support the general case.

If later in the process you discover a case that you overlooked, then it is 
a simple matter to add a test for the new case and modify the code to 
support it while being sure you aren't breaking other cases.

Duncan Booth                                             duncan at
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?

More information about the Python-list mailing list