[Python-Dev] unittest output

Thomas Heller theller at python.net
Wed Dec 3 09:40:42 EST 2003

Guido van Rossum <guido at python.org> writes:

>> > > When a test fails, it is accompanied by tracebacks that include
>> > > all the processing within the unittest module itself.  This makes
>> > > it darned difficult to see at a glance what went wrong.  If like
>> > > me, you use unittest as part of the development process, then you
>> > > run it hundreds of times each week and this eyesore gets to be a
>> > > real PITA.
>> > >
>> > > I don't recall when or where, but someone has proposed a fix.
>> > > But, like many great ideas, it got stymied because someone,
>> > > somewhere has a use for the rest of the traceback.   Also, a
>> > > developer raised the (IMO red herring) issue -- what if there
>> > > is a bug in the unittest module, how would you track it.
>> > 
>> > http://www.python.org/sf/722638
>> Arghh.  I had forgotten that Steve Purcell weighed in on this.
>> It's his module.  So unless he can be persuaded, the point is moot :-(
> Not so fast.
> The patch claims to only suppress the traceback if the test *failed*
> (e.g. called self.fail(), or one of the assertXXX variations failed).
> If the test raised an unexpected exception (unittest calls this an
> *error*) the traceback is printed normally.  This seems right to me.
> A refinement could be to make the output *look* like a (short)
> traceback as printed by the traceback module even in the failure case;
> this would address Steve's issue tht IDEs find lines in the code via
> the traceback.  And there should be a command line switch and an
> environment variable to show the full traceback in all cases.

The patch does this, also.  My original usecase was that I wanted Xemacs
to automatically go to the line of the failed test, and not inside the
unittest source line where the exception was raised.

And the patch *only* suppresses the deepest frame (that inside the
unittest source code), if the traceback is n levels deep, n-1 levels
are printed.

At least this was my intention, if the patch has a chance to make it in,
I'll try it again, and bring it up to date if needed.

(Another question is this: is raising an exception the right thing to do
when a test fails? I'm not so sure, although changing this would be a
much bigger change...)


More information about the Python-Dev mailing list