Issue451309
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-08-15 20:36 by jhylton, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
*vc-diff* | jhylton, 2001-08-15 20:36 |
Messages (6) | |||
---|---|---|---|
msg5950 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2001-08-15 20:36 | |
A TestResult object stores the exceptions raised when tests fail. The only use of these stored tracebacks, it seems, is to print a stack trace when the test run's report is generated. The traceback objects, however, keep pointers to a bunch of objects that might otherwise be garbage collected. I ran into this on Windows, where the traceback was keeping a file object alive. Because the file object was not collected, my tearDown() method could not remove the file. This patch changes unittest to generate the formatted traceback immediately, so that it does not keep tracebacks around any longer than needed. |
|||
msg5951 - (view) | Author: Steve Purcell (purcell) | Date: 2001-08-15 21:46 | |
Logged In: YES user_id=21477 Hi Jeremy, This behaviour is actually known and intentional; the dangers are documented as a caveat in the PyUnit docs. The intention was that a test runner (GUI or otherwise) could potentially make the traceback available for inspection when a test fails, to aid in debugging. In your particular case, relying on GC to close the file might have caused problems with following code even if PyUnit didn't store the traceback. Overall I'd prefer to keep storing the tracebacks, especially since they only get stored when tests fail. It would be worth me adding a note about GC interaction to the docs, though. |
|||
msg5952 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2001-08-16 15:38 | |
Logged In: YES user_id=31392 I think this feature is more trouble than it's worth. If a testrunner wants to capture the actual exception, it could easily override the addError or addFailure method to get the traceback then. The cost of the feature is high, particularly since it is not used by anyone. The effects of preserving tracebacks can be hard to discern, and I expect when it happens it will cause a lot of confusion. In my case, two experienced Python programmers, who are novices with unittest, spent several hours trying to figure out what went wrong. I don't think updating the docs will be particularly helpful, because this situation is somewhat unusual and the current behavior so surprising. |
|||
msg5953 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2001-08-28 15:27 | |
Logged In: YES user_id=31392 We had a water-cooler conversation about this issue. It was observed that keeping tracebacks alive until the end of a test suite isn't very useful, because any number of objects on the stack may be mutated during the subsequent run of the program. In general, a traceback object should be handed to the debugger right away or processed in some other way. |
|||
msg5954 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2001-09-05 18:12 | |
Logged In: YES user_id=6380 Jeremy, can you propose a patch for this? Steve isn't going to fix it without some help. |
|||
msg5955 - (view) | Author: Steve Purcell (purcell) | Date: 2001-09-06 08:27 | |
Logged In: YES user_id=21477 I've made a fix now. From the CVS checkin message: Changed TestResult to store only the text representation of an error. This patch is similar to that proposed by Jeremy. The proposed patch altered the interface of TestResult such that it would be passed the error information as a string rather than an exc_info() tuple. The implemented change leaves the interface untouched so that TestResults are still passed the tracebacks, but stor them in stringified form for later reporting. Notes: - Custom subclasses of TestResult written by users should be unaffected. - The existing 'unittestgui.py' will still work with this module after the change. - Support can later be added to pop into the debugger when an error occurs; this support should be added to a TestRunner rather than to TestCase itself, which this change will enable. (Jeremy, Fred, Guido: Thanks for all the feedback) |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:19 | admin | set | github: 34972 |
2001-08-15 20:36:16 | jhylton | create |