#30249: Deprecate re-raising view exceptions from test client in tests
-------------------------------------+-------------------------------------
Reporter: Jon Dufresne | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jon Dufresne):
> Some helper would be better yes. `assertResponseException()` or such.
Yeah, I definitely agree. In my latest revision of the PR, I've added
`SimpleTestCase.assertRequestRaises(response, expected_exception,
expected_message)` along with documentation and tests.
With this in place, tests are now exactly the same size as before:
{{{
with self.assertRaises(AttributeError):
self.client.get(reverse('admin:admin_views_simple_changelist'))
}}}
Becomes
{{{
response = self.client.get(reverse('admin:admin_views_simple_changelist'))
self.assertRequestRaises(response, AttributeError)
}}}
---
I'm open to taking a different approach to triggering the old behavior.
Ultimately, my goal is to have the test client not skip parts of the
Django request/response stack by default -- bring `Client` closer to
acting like a real world HTTP client. If that is through the existing
setting or a new kwarg, either is fine with me.
I'll respond to your comments above as they're presented, but again, I'm
happy to compromise on an alternative path.
> rather it's using a setting, which has other purposes, to control the
test-client behaviour.
Sorry, I'm not sure I follow. This setting is documented as:
> If set to True, Django’s exception handling of view functions
(handler500, or the debug view if DEBUG is True) and logging of 500
responses (django.request) is skipped and exceptions propagate upwards.
>
> This can be useful for some test setups.
IIUC, that is exactly what you're trying to achieve in your tests. That
is, the 500 handler is skipped and the exception is raised by the caller
(in this case, a test method).
> I like and use the current behaviour.
Yup, I understand. This behavior will continue to be available to those
that want it by using the existing setting. That isn't going away.
> Maybe one-day we remove `DEBUG_PROPOGATE_EXCEPTION`, for a custom
`handler` subclass or such. What do I do then? (For me 🙂) clearly the
right answer is a flag on `TestClient`, which we already have.
No one is suggesting `DEBUG_PROPOGATE_EXCEPTION` be removed nor have I
ever seen such a suggestion outside this ticket. I'm not sure where this
is coming from.
---
If you still disagree with the overall aim of the ticket, then I'll
prepare something to discuss further on the mailing list. If you disagree
only on some of the details, then I think we can work out a compromise
that fits both our needs.
Thanks again for the responses and discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/30249#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.b7b1f4d33a12a40de32bd915c40ca089%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
