On Wed, Jun 29, 2011 at 12:21 AM, Yo-Yo Ma <[email protected]> wrote: > Problem: > > When using the test client, it's simple to check for a 200 response > code, but not quite as simple to quickly determine, why a 500 was > encountered, in the case of a test failure. > > Proposed Solution: > > A new test method which expects a status code of X, and when a 500 is > encountered instead, the error that caused the 500 is output for ease > of debugging, such as (one idea for the interface):
I'm a little confused about what you're proposing. The usual case for receiving a 500 is when a view raises an exception; however, if you're using the test client, any exceptions raised by the view are re-raised as exceptions, not handled as 500 errors. This means that whenever a 500 error is raised, you are presented with the full stack trace, which you can either catch in your test case as an expected failure, or allow to surface as an error in your test case. Django's test suite contains examples verifying this exact behavior (e.g., test_client.ClientTest.test_view_with_exception in modeltests). This isn't a recent addition, either -- it's been the behavior of the test client from the beginning. So - what is the use case you have where this sort of handler would be necessary? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
