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

[Peter Hansen]

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

Richie Hindle wrote:

> If you're not doing so already, start using Test-Driven Development.  Google
> will give you any number of resources about that, but in a nutshell it means
> writing unit tests *before* writing code, then writing the code to make the
> tests pass.  This forces you to think about the design of your modules up
> front, and usually leads to better-designed software.  The modules you write
> will have cleaner interfaces and will be less dependent upon each other,
> more clearly written, more reusable, and more amenable to changing without
> breaking things.

As Richie is (self-admittedly) somewhat new to TDD, I'd like to tweak
the above description about how it works, though the final sentence is
exactly correct about the results.

Even though it used to be called "test-first", saying the tests are
written *before* the code is actually misleading.  A single test is
written before any code, then run (and it should obviously fail!),
and then some code is written, just enough to pass the test.  Once
that test passes, the code is cleaned up if necessary, then another
test is written, and the cycle begins again.  It will generally
take a few minutes for an entire cycle, sometimes more, sometimes less.

And although Richie is right that this will make you think more about
the design, I'd argue the "up front" claim and say that it makes you
think about the design all the time, rather than *merely* up front
as with some other approaches.  Doing it up front only is like
pointing your car in a particular direction, then hitting the gas
and not turning the wheel until you get there.  It can work, but
a lot of people get hurt in the process.  Doing it all the time
is like driving really works, where you actually pay attention and
turn the wheel from time to time.  (Note that you can still hurt
people this way, if you want, so all the fun is not removed.)

> The other important feature of test-driven development is that it's *hard*,
> or at least it's hard for some application areas (like networking and GUIs).
[...]
> A question for experienced TDD-ers: is TDD really more intellectually
> demanding than code-first, or am I either a) doing it wrong, or b) stupid?

TDD is both harder and easier, I think.  Once you're practiced with it,
most of the small stuff -- "typical" code -- becomes fairly trivial
and thus less demanding than trying to do it the typical way (code
and fix, resorting to debuggers to step through code, lots of print
statements and head-scratching, manually tests).  On the other hand,
for non-trivial stuff, such as GUIs, threading, networking, etc, the
fact that it requires you to write automated tests definitely forces
you to think harder about difficult things, and to face challenges
other programmers never have to face.

As Richie's client/server example showed, sometimes tests can get out
of hand.  You can live with them, or you can refactor and clean them
up.  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.  So Richie, you're definitely
not stupid, but you're probably still new enough at it that you're
learning some valuable lessons.  (That's my more positive way of saying
you were doing it wrong. ;-)

-Peter