No subject

the highest level possible (i.e. load a web page, run a script,
doctest) and then follow up with the implementation to pass the test.
I like to work my way down to the unit level prudently since once you
get down to testing the unit you have a lot more maintenance to do if
you want to change the implementation that passes your high-level
test.

When I've worked with developers who've struggled with test-driven
development I've noticed it's generally because they are trying to
start testing at a very low level, the unit test.  I think this is a
hard place to start because the problem you are trying to solve is
staring you in the face (the web page, the xml files you need to
parse) and the idea of solving that with several units of code is an
unimportant detail.  Testing helps you understand the interface, not
the implementation, so starting at a small level seems
counter-intuitive to me.  Thus, I would suggest to anyone who
struggles with test driven development to try testing from the
"outside", testing the interface first, before it works.

There are a couple tools for this -- twill [1], PyFIT [2], fixture [3]
come to mind -- but it's really just a concept.  There is a ruby
module that tries to encapsulate this concept which is sort of
interesting: http://rspec.rubyforge.org/ .  They call this "behavior
driven development" which also makes a little more sense.  However,
Ian Bicking wisely pointed out that doctest is a very fine example of
doing behavior driven development in python :
http://blog.ianbicking.org/behavior-driven-programming.html

[1] http://twill.idyll.org/
[2] http://agiletesting.blogspot.com/2004/11/writing-fitnesse-tests-in-python.html
[3] http://code.google.com/p/fixture/