Test-driven development and code size

[Ryan Ginstrom]

> On Behalf Of Joel Hedlund
> My presumption has been that in order to do proper 
> test-driven development I would have to make enormous test 
> suites covering all bases for my small hacks before I could 
> getting down and dirty with coding (as for example in 
> http://www.diveintopython.org/unit_testing). This of course 
> isn't very appealing when you need something done "now". But 
> if I understand you correctly, if I would formalize what 
> little testing I do, so that I can add to a growing test 
> suite for each program as bugs are discovered and needs 
> arise, would you consider that proper test-driven 
> development? (or rather, is that how you do it?)

Have you looked at nose?
http://somethingaboutorange.com/mrl/projects/nose/

It automatically discovers your unit tests and runs them. I have a command
in my Komodo toolbox that runs the nosetests script on the current
directory. So the overhead of writing (and running) unit tests is very
small.

Usually, even when developing one-off scripts, you'll try some test cases,
maybe do some testing at the interactive prompt. That can serve as the basis
of your unit tests. Then maybe the first time you want to import that module
from another script, you can beef up your unit tests then.

If unit testing seems like too much work, people won't do it. So I think
it's good to start out by doing just enough unit testing that it's not
onerous. As you see the benefits, you'll probably seem them as less onerous,
of course.

Regards,
Ryan Ginstrom