[Python-Dev] unittest output

[Guido van Rossum]

> > > 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.

I'd also plead for a switch to let unittest *not* catch exceptions at
all -- there are situations where you really want to invoke a debugger.

The IDLE issue is separate; I agree that IDLE should treat SystemExit
differently (simply go back to the >>> prompt without printing a
traceback, printing the status only if it is true).  You should add
this to the idlefork SF tracker so Kurt can address it.

--Guido van Rossum (home page: http://www.python.org/~guido/)