Tres Seaver <tseaver@palladion.com> 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