DoTheSimplestThingThatSatisfiesTheTests

1 Think of a test and implement it (well, think of many, but implement one) 1 implement the simplest thing that satisfies the test (usually hardcode some return values!) 1 write another test 1 satisfy both tests in the simplest way (hardcode with a conditional?) 1 refactor, apply 'once and only once' . ..etc..

This technique appears to have the following emergent properties:

• the testing is more complete

My brain tries to think of ways to out-smart the test with a simpler implementation than the subconciously intended one. This in turn forces another test to keep the code on the straight-and-narrow.

• iterations are quicker (usually a couple of minutes), since the implementation is allowed to build at a finer grain.

• refactoring becomes the most intuitive way to design.

After three or four iterations, I'm confronted with a load of smelly 'raw-material' code. In the early iterations the simplest thing often includes hardcoding values and breaking encapsulation (this is python after all!). A brief refactoring session eliminates the redundancy, and better expresses the current state of intention. After this session, the simplest thing to satisfy the next test becomes more likely to leverage the emergent framework. - PhilDawes

TomAyerst informs me that this is how Wiki.KentBeck does it. ³host³³date³October 2, 2001³DoTheSimplestThingThatSatisfiesTheTest ³³agent³Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)³DoTheSimplestThingThatSatisfiesTheTests