On 7/13/05, Chris Withers <[EMAIL PROTECTED]> wrote:
> Ever noticed how tracebacks from ZPT are actually quite useful when
> viewed through the error_log object, but totally useless when they fail,
> say, in a unit test?

Yeah. 

> This bugged me, so I had a dig, and just discovered this cool monkey
> patch, to be inserted in any module that gets imported before an
> exception is raised:

So, could this be in the unit test module itself, for example?

And a question for you:
Ever noticed how it's near impossible to figure out what actually
causes an error when you run functional tests? Can you fix that too?
:-)

I used to do this in all my functional test cases:

    def getTraceback(self, response):
        return getattr(response._response, '_text_traceback', None)

    def assertResponse(self, response, status, message=''):
        if not response.getStatus() == status:
            tb = self.getTraceback(response)
            if tb is not None:
                raise self.failureException, tb
            else:
                raise ValueError, "Response had status %s, expected %s. %s" % (
                    response.getStatus(), status, message)

And then end all my tests with:
        self.assertResponse(response, 200)

And that _used_ to print out any exception that had occurred, but in
newer version of Zope this never happens. There sinmply never is and
_text_exception on the response anymore. Any ideas on how to get a
useable exception report on unit tests?

-- 
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/
_______________________________________________
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to