on TDD (was Re: how to become a really good Python programmer?)

[Richie Hindle]

[Peter]
> (Yes, yes, I can see you smiling, you who was just waiting for my
> response... or John's. :-)

<innocent-expression>Oh, so you're into TDD, Peter?  I had no
idea.</innocent-expression>

Thanks for clarifying my summary of TDD - I can see how it might have been
misunderstood.

> Once you've been down that path once or twice, you will start to
> see the warning signals well in advance, and eventually you will just
> do the thing he concluded should have been done, automatically and
> without thinking much, right at the start.

I'm looking forward to it.  8-)

For others looking to learn more about TDD, I've found this paper:
http://www.edwardh.com/ieee_article/goingfaster.pdf
useful as an introduction to the principles of TDD - not the nuts and
bolts of how to practise it, but ideas like splitting your core code
(eg. my RPC protocol) away from hard-to-test external libraries
(eg. sockets).

I think one of the problems I'm having is that I'm thinking like a
module coder rather than a test coder.  A question for any passing
TDD-er (not with anyone specific in mind, of course, smart questions
and all that 8-) - how much does the design of the module and its API
get influenced by the requirement of writing tests for it?  A coder
has two tasks: write a module (and the code that needs to use it), and
write tests for it.  Both will have some bearing on the interface to
the module, but in what proportion?  My suspicion is that 75% of the
design of the module's API will fall out of the way the tests are
written, and that that's a good thing...?

-- 
Richie Hindle
richie at entrian.com