paste eating exceptions in test suite that would otherwise be shown in debugger

[Jamie Wilkinson]

Dunno how many of you are using paste.fixture to be good little programmers
and test your webapps, but hopefully you all are and have come up with a
solution to this one:

I'm often getting errors trapped by the exception handler in Pylons, and in
normal operations this would be fine, because it'd redirect to the debugger,
and you get the opportunity to see the traceback.

Within paste.fixture, when this happens, you don't get a useful traceback,
you get a traceback from wsgilib throwing an AssertionError: No Errors
should be written, because it caught an AssertionError: no errors should be
written (ironic?).. because it caught "Debug at:
http://localhost/_debug/view/...".

So what I really want is to see the real traceback in the test suite runner
that I'd be seeing in the browser.

Has anyone found a good workaround to this?

If not, does anyone know where the best place to start tracing this back so
I can patch paste to re-raise the correct exception?

which leads me to ask.. Why does paste even worry that an error was written?
(Maybe that's a better question for the paste list?)

[Ben Bangert]

On Jul 26, 2006, at 9:55 PM, Jamie Wilkinson wrote:

> Within paste.fixture, when this happens, you don't get a useful
> traceback,
> you get a traceback from wsgilib throwing an AssertionError: No Errors
> should be written, because it caught an AssertionError: no errors
> should be
> written (ironic?).. because it caught "Debug at:
> http://localhost/_debug/view/...".
>
> So what I really want is to see the real traceback in the test suite
> runner
> that I'd be seeing in the browser.
>
> Has anyone found a good workaround to this?
>
> If not, does anyone know where the best place to start tracing this
> back so
> I can patch paste to re-raise the correct exception?
>
> which leads me to ask.. Why does paste even worry that an error was
> written?
> (Maybe that's a better question for the paste list?)

Yes, even if the traceback isn't shown, it will still toss a 500 giving
you the same issue. paste.fixture assumes you want a 200 response,
anything else and it blows. If you are expecting a 500 response,
telling it you expect this will make it not throw an exception there
(according to the docs). So I believe you'd want to do the request like
so:
resp = app.get('/something', status=500)

Which will then work (though I haven't tested this personally....).
Docs here:
http://pythonpaste.org/testing-applications.html#the-tests-themselves

Let me know how that works out.

HTH,
Ben

[Jamie Wilkinson]

This one time, at band camp, Ben Bangert wrote:
>Yes, even if the traceback isn't shown, it will still toss a 500 giving
>you the same issue. paste.fixture assumes you want a 200 response,
>anything else and it blows. If you are expecting a 500 response,
>telling it you expect this will make it not throw an exception there
>(according to the docs). So I believe you'd want to do the request like
>so:
>resp = app.get('/something', status=500)

Right, forgot about testing status.

The thing is, if my test is failing due to an exception, I don't want
anything to trap it, because I want to debug the test :)

So, I don't know I'm expecting a 500, generally. I certainly don't want to
have the test pass if a 500 gets thrown in this instance.

[Ian Bicking]

The error-catcher shouldn't be in place, or at least not activated.
When using paste.fixture it sets environ['paste.throw_errors'] = True,
which both error catchers should(?) respect and thus let exceptions
bubble all the way up to your test runner. This is done in
paste.evalexception.middleware:275 and paste.exceptions.errormiddleware:128.

--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org

[Ben Bangert]

On Jul 27, 2006, at 9:09 AM, Ian Bicking wrote:

> The error-catcher shouldn't be in place, or at least not activated.
> When using paste.fixture it sets environ['paste.throw_errors'] = True,
> which both error catchers should(?) respect and thus let exceptions
> bubble all the way up to your test runner. This is done in
> paste.evalexception.middleware:275 and
> paste.exceptions.errormiddleware:128.

Ahhhh... yes, we use a custom evalexception for the skinned version.
Looks like its catching it with evalexception when it shouldn't be.
I'll add a ticket for this as I'd like it cleared up before 0.9 release
and its pretty minor I believe.

Thanks for the info on that.

- Ben

[Jamie Wilkinson]

This one time, at band camp, Ben Bangert wrote:
>

Cheers guys :)