Debugging Python

[Mike C. Fletcher]

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.

Have fun,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/