[sapug] Python Resource: Testing In Python Mailing List.
dt-sapug at handcraftedcomputers.com.au
Thu May 31 06:24:12 CEST 2007
Chris Foote wrote:
> I've toyed with PyUnit a little bit (http://pyunit.sourceforge.net)
> but I don't really understand test driven development.
I'm still split on its merits, given the amount of bug free code
that I write :-), but it's still something I'm coming to grips
with (despite my surname, it ain't second nature). About a year
ago I did write some fairly baroque "accounting code" that
benefited a lot from writing the test code up front, but then
(to me) that's more nailing its specification than anything else
(although I did add corner test cases later as I found them).
But that was an independant module that had little in the way of
external dependencies, and I think that's the easiest of cases.
Not all problems decompose so easily.
> To me it seems like you'd spend far too much extra time getting your code
> to fit the tests than getting real work done, especially with projects
> than involve lots of external components like databases, distributed
> procedures and actions that take place in the background using threads.
It's at this point where I come unstuck too. You are right in that
test firsting your code does modify its structure, and presumably
once you've had enough practice then it becomes easier, but I'm
still grappling with getting mock objects inserted into strategically
placed positions in "substantial" code (and here I'd be looking at
more end to end than unit testing). My problem (experience?) here
has been that I try to test only behaviour (more along the interface
lines) than the implementation, so I like to keep my tests only
loosely coupled to the code. Once the tests start getting into the
"OK, I need to mock all the objects which cause side effects, so
I'll need a postgres and ldap object, and patch in this replacement
module" then you start spending too much time keeping the tests "in
tune" with the implementation. Doctest'ing appears to be more
interface approached, although I haven't had as much experience
with it as unit testing.
Retroactively fitting tests seems to be a level of hardness again,
so I think the decision to do substantial unit testing has to be
made up front (certainly hard enough that someone's devoted a
book to the topic :-).
> Having code not break when getting modified by herds of software engineers
> would have to be a good reason to use it, but aren't its benefits very
> limited for one or two man projects ?
I think it depends on the nature of the project. The "spec. nailing"
example I did was where I first got the tickle that it would work
(and in its subsequent refactorings which were done a few months
later, when implementation details weren't so fresh in my mind).
For a while I've wanted to rewrite one of my more substantial
Python modules to make it more testable, but I think my approach
is wrong - I'm too bogged down by its current implementation
(thinking "How will I test this particular component") to figure
out where to start (and throwing away perfectly working code
doesn't sound like much of a win either).
"My god, it's full of 'car's!" - "LISP", http://xkcd.com/c224.html
More information about the sapug