Re: zope.testing.testrunner.debug.post_mortem and try/finally
Ross Patterson <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Message-ID | <[email protected]> |
Tres Seaver <[email protected]> writes: > Ross Patterson wrote: >> When a try/finally clause is (appropriately) used to do cleanup after an >> exception during a test run, it often tears down parts of the fixture >> that are needed in order to do useful post_mortem debugging of the >> exception, such as closing the request or db connections. What is the >> best way to do post_mortem debugging with the stack in the state it was > >> at the time of the exception? >> >> For a while now, I've been repeatedly modifying eggs in my development >> environment at the relevant try/finally clauses to invoke post_mortem >> before the tear down is done, sub-optimal to say the least. :) I find >> myself doing it often its time to invest in a better way. >> >> Is there some Python voodoo I'm unaware of to get a post_mortem to >> reflect the stack before try/finally clauses? If not, is putting >> some sort of hook into the relevant try/finally clauses the best way to >> address this? If not, what should I be doing? >> >> If putting hooks into the try/finally clauses is the right way, then it >> would be nice to have a somewhat canonical way to do this. It would >> also be nice to have a way to pass something down the line so that >> post_mortem() only gets called once per exception. > > Are you using try:...finally:... inside your testcase methods? If so, > why not just move the cleanup invocation into your 'tearDown' for the > testcase class: at that point, the '-D' option to the testrunner will > stop you at the error, with the tearDown not yet called. I'm sorry, I was unclear, the try/finally clauses are not necessarily in *test tearDown* methods (though I used that language), they are often a part of the application being tested, such as closing the request, closing DB connections, or aborting transactions. > Or are you doing this in doctests? If so, move the code you are testing > into a real testing framework. ;) Oh, goody. Derogatory evangelism. :) Doctests have tearDown just like other tests. Ross _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )