[sapug] Python Resource: Testing In Python Mailing List.

Michael Davies michael at msdavies.net
Wed May 30 15:35:38 CEST 2007


On 30/05/07, Chris Foote <chris at inetd.com.au> wrote:
> I've toyed with PyUnit a little bit (http://pyunit.sourceforge.net)
> but I don't really understand test driven development.
>
> 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.
> Maybe I'm missing a big piece of the testing puzzle :-(
>
> 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 ?

Well, I'd say no :-)

Your tests also define your requirements in a far more concrete way
than any externally developed and updated spec.  While the code might
be the definitive definition of what your software does, the tests
document implicit behavior, moving that behaviour to become an
explicit requirement, and hence persistent through subsequent
modification (even by yourself - who can remember the code they wrote
last month?  Or even last _week_!?!?)

I'd also say that TDD also encourages you to only write the code you
need to.  Far too often we're asked to build a rope bridge over a
ravine, and instead we build a harbor bridge :)  TDD makes us think
about what we're building.

TDD encourages us to write code that is testable - meaning that when a
critical bug does come in, you don't have to resort to a debugger -
it's going to be more likely to be able to write a test to catch that
heisenbug (corollary: Having unit tests for a multi-threaded system is
far better than trying to use a debugger in a multi-threaded system)

TDD also improves your productivity - since you're not trying to come
up with the grand unified theory of everything, but rather writing
only enough code to satisfy the next test, you get more done.  The
demotivation of hard problems is dissolved into small tests with small
solutions.

Regarding the problem of interfacing to external databases and network
resources, making use of mock objects can alleviate this.  It's still
more work, but helps us to solidify interfaces and understand the
problem better.  Eat your greens, they're good for you :)

Of course, TDD is much easier when starting a project from scratch.  I
have a 30KSLOC non-python code base right now where we're trying to
retrofit unit tests and implement TDD practices going forward.  Let's
say it's not fun[1].  But we're already experienced some benefits -
refactoring has been easier than expected for adding new
functionality.

So to summarise, I'm a convert.  It's TDD for me!

Michael...

[1] But the testing framework is partially in Python, so there's _some_ fun :-)
--
Michael Davies           "Do what you think is interesting, do somthing that
michael at the-davies.net    you think is fun and worthwhile, because otherwise
http://michaeldavies.org  you won't do it well anyway." -- Brian Kernighan


More information about the sapug mailing list