Unit testing - suitable for all development?

Kylotan kylotan at hotmail.com
Mon Mar 8 21:22:38 CET 2004

jjl at pobox.com (John J. Lee) wrote in message news:<87k71wi3lq.fsf at pobox.com>...
> kylotan at hotmail.com (Kylotan) writes:
> > None of this makes testing any harder or less useful in catching bugs;
> > it just means that it ends up being an almost straight duplication of
> > my normal code, with the input handling stripped out! It hardly seems
> > worth the effort.
> That's right: you write the test, you think "this test code is so
> trivial it hardly seems worth the effort".  Then you run them, and you
> think "OK, maybe it's not so trivial".  OK, most (but not all) of the
> bugs you find in that process are in the tests, not the code.  Just as
> important, though, it makes you think about what you're writing,
> reducing coupling.

I suppose that it would be a good tool in that sense, yes. I'm still
undecided as to whether it provides a significant benefit over an
extensive object-oriented background though.

> Then, later, you break your code, and the trivial,
> obvious, unit test saves a lot of time.  Then, later, if you
> reimplement your interface, and spend a good solid chunk of time
> rapidly fixing bug after bug after bug in the new implementation (each
> bug revealed by the tests), you'll wonder if it would even have been
> *possible* to reimplement it without the unit tests.

This is one thing that puzzles me. I don't write bug-free code - far
from it - but I can't say I remember any significant times when I
introduced code that broke earlier code. I follow the Firefox and
Thunderbird open source projects and often hear about 'regressions' in
the latest builds. This surprises me, as I just don't get this in my
own work. I suppose the main difference is that my projects are an
order of magnitude smaller and every line of code is written by

Ben Sizer

More information about the Python-list mailing list