Mike C. Fletcher
mcfletch at rogers.com
Sat Jan 10 17:48:00 CET 2004
Alan Gauld wrote:
>On Fri, 9 Jan 2004 10:29:46 GMT, Harry George
><harry.g.george at boeing.com> wrote:
<think this was actually Peter in here>
>>>I'm not sure about others, but when I design and code using test-driven
>>>development (TDD), I tend not to need to debug almost ever.
>Interesting comments. How do people generally perform these tests
>then? My primary test tool, for low level testing, is usually the
>debugger. Batch mode debugging is something I've been doing since
>I worked on VAX/VMS systems and its seems as natural as breathing
>to me. Its easy to save a test session and run it later etc. How
>else do you test code at a low level?
Standard module unittest, although lots of people like doctest (closer
in spirit to your debugger debugging traces). The TDD/Agile people seem
generally to use the more formal unittest mechanism (which is more
appropriate when you're writing the test first), while doctest
encourages you to write something closer to a "regression" test, where
you're just testing that what works now isn't going to fail in the
future by recording side-effects (debugger/prompt output) and comparing
them to the later version's side-effects.
unittest testing is a rather involved thing, there's all sorts of
test-framework "fixtures", (e.g. MockObjects), that help you run a
particular method of a particular object all by its lonesome to test
that it does everything it is supposed to do and nothing it's not
supposed to do. The entire test-suite is supposed to be run regularly
(at least daily & before checkins), with local tests (those for the area
on which you are working) being run every 30 seconds or so as you write
new tests (and then the code to fix the breakage of those tests (and
that only if the test is actually broken with the current code-base)).
TDD (test-driven development) tends to reduce/eliminate the use of the
debugger because of that (automated) frequency of test-code-runs.
You're testing small blocks of code with tests whose very name says
what's failed about the block of code, so as soon as you screw something
up red lights start flashing telling you what you just did wrong. Given
that you're also *working* on very small code blocks, you generally know
what you just did (you aren't supposed to be coding large blocks of code
at once), and the failed tests' names tell you what went wrong (and
where) with what you just wrote.
I've only been able to rigorously apply TDD in one or two projects so
far. The fit for GUI and graphics code isn't spectacular (IMO).
Command-line, library, and network apps (with the appropriate test
fixtures (efficient use of which seems to be key to any serious use of
TDD)) seem to be a better fit.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list