Hash: SHA1

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.

Or are you doing this in doctests?  If so, move the code you are testing
into a real testing framework. ;)

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to