[Python-Dev] unittest output (original) (raw)

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

Thomas

More information about the Python-Dev mailing list