In my quest to reduce the impact of not having a pair (freesoftware can be a lonely activity), I've started using the following technique with favourable results (so far):
Think of a test and implement it (well, think of many, but implement one)
implement the simplest thing that satisfies the test (usually hardcode some return values!)
write another test
satisfy both tests in the simplest way (hardcode with a conditional?)
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
Is this the norm amongst XPers? --PhilDawes
TomAyerst informs me that this is how [Wiki.KentBeck] does it.
DoTheSimplestThingThatSatisfiesTheTests