Debugging Python

[Harry George]

When I need to, which is rare, I either use print statements (a very
solid technology dating from, oh, last century sometime ;-), or the
Python debugger module: pdb.

Actually, all I ever do with pdb is this:

# this is just before the code that I think is failing
import pdb
pdb.set_trace()

# code that I'm about to trace through goes here


And about the only features of pdb I've had to use are "r", "n", and
the ability to inspect arbitrary variables.

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. The need
to debug is usually when you aren't sure where a typo, or logic error,
or other mistake has actually occurred. When using TDD, it's exceedingly
rare that when a test fails, I don't know exactly where the problem is
without having to resort to traditional (slow, tedious, annoying) debugging.

-Peter

Interesting. A python newbie asked me the same thing yesterday and I
told him almost exactly what you said: If you are doing test-based
(whether or not it is with someojne else and thus Agile), you don't
get into those grim debug sessions that are part of life in C/C++
land.

Actually what I said was something like

"If you don't make mistakes, you don't need a debugger. The way to
avoid mistakes is to test everytime you edit a line or two of code.

"If you need to, use my homegrown debug statements (which print the
module and method/function name, the message, and then flush). If you
really get stuck, there is a debugger, but typically you just need
debuggers to solve memory problems. Python mistakes tend to be much
higher level, and pretty obvious once you see the data values."

 

[Ashley Lloyd]

What do people generally use to debug their Python programs? I haven't seen
anything out there that walks through the code, but perhaps I'm looking in
the wrong places?

TIA

Ashley

_________________________________________________________________
Tired of 56k? Get a FREE BT Broadband connection
http://www.msn.co.uk/specials/btbroadband

 

[Peter Hansen]

What do people generally use to debug their Python programs? I haven't seen
anything out there that walks through the code, but perhaps I'm looking in
the wrong places?

When I need to, which is rare, I either use print statements (a very
solid technology dating from, oh, last century sometime ;-), or the
Python debugger module: pdb.

Actually, all I ever do with pdb is this:

# this is just before the code that I think is failing
import pdb
pdb.set_trace()

# code that I'm about to trace through goes here


And about the only features of pdb I've had to use are "r", "n", and
the ability to inspect arbitrary variables.

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. The need
to debug is usually when you aren't sure where a typo, or logic error,
or other mistake has actually occurred. When using TDD, it's exceedingly
rare that when a test fails, I don't know exactly where the problem is
without having to resort to traditional (slow, tedious, annoying) debugging.

-Peter

 

[Alan Gauld]

told him almost exactly what you said: If you are doing test-based
(whether or not it is with someojne else and thus Agile), you don't
get into those grim debug sessions that are part of life in C/C++
land.

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?

Or does using the debugger as a test harness not count as
debugging?

Alan g
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

 

[Mike C. Fletcher]

On Fri, 9 Jan 2004 10:29:46 GMT, Harry George

....

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/

 

[Frithiof Andreas Jensen]

Interesting comments. How do people generally perform these tests
then?

I use the unittest module.

It is *tedious* as hell to get the test cases up and running in unittest but
I find that it always takes less time and effort in total to take the pain
up front instead of debugging "later".

Often difficulties with the test code inspires one to rethink an interface
or a design, something one would not like to do on a larger collection of
code that "almost" runs.

 

[Peter Hansen]

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?

Or does using the debugger as a test harness not count as
debugging?

The debugger-as-test-harness does not count as testing, anyway, at
least not in the Agile sense. The tests *must* be automated, and
run very frequently (constantly) or you can't be very agile.

As others have said, the unittest is the key (in Python) or at least
the de facto standard. I would not agree that using it is "tedious"
at all, however, as it takes me only about twenty seconds to start a
new test file and that's *without* using a template. Running the tests
is also not tedious, at least not if you invest a few hours in a
simple utility that automates even the run-all-tests functionality.
I just type "unit -a" and all tests in all subfolders are immediately
run, without output going to a log file for later analysis in case
there are failures.

-Peter

 

[Frithiof Andreas Jensen]

...., as it takes me only about twenty seconds to start a
new test file and that's *without* using a template.

.....in twenty seconds you can just about write "import unittest" ;-)

I find that a simple module will need about three to five tests for each
method in each class and probably some test data as well often yielding in
total *more* lines of test code than the module I want to test.

It is simple, stupid & boring code but still lines that have to be typed and
debugged.

*That* is tedious work. Always will be.

The benefit comes later - when improving and extending the module one can
immediately see if it breaks and also I find that if one cannot think of an
obvious way of testing some class/method/unit it is usually because the
interface is stupid and needs a redesign.

The real fun with unittest starts when using "other peoples code": I wrote
an accounts database module based on pySqlite for a horse racing program I
am (still!) writing for fun. That was not at all easy to get to run in such
a way as one could test the database functions properly with unittest. There
is a lot of massaging of data to test that the queries work as intended and
manual work to design SQL data that will yield simple tests.

OTOH I am pretty confident the implementation actually works and I even
think I understand the kinks in pySqlite's implementation of the python
database API too ;-).

 

[Michele Simionato]

....in twenty seconds you can just about write "import unittest" ;-)

I find that a simple module will need about three to five tests for each
method in each class and probably some test data as well often yielding in
total *more* lines of test code than the module I want to test.

It is simple, stupid & boring code but still lines that have to be typed and
debugged.

*That* is tedious work. Always will be.

That's why I use "doctest" much more than "unittest".

Michele

 

[Peter Hansen]

....in twenty seconds you can just about write "import unittest" ;-)

You don't know how fast I type. ;-)

import unittest

class TestCase(unittest.TestCase):
def test01(self):
pass

if __name__ == '__main__':
unittest.main()


== 23 seconds... counting launching Scite! <grin>

I agree with all your other points though.

-Peter