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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4