#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 Carlton Gibson):
Hey Jon.
You've only quoted part of the description for
`DEBUG_PROPAGATE_EXCEPTIONS`. The whole thing goes like this:
> This can be useful for some test setups. It shouldn’t be used on a live
site unless you want your web server (instead of Django) to generate
“Internal Server Error” responses. In that case, make sure your server
doesn’t show the stack trace or other sensitive information in the
response.
So the other use is having your web server handle the 500 (or whatever)
rather than Django doing it. Nothing to do with testing.
Now I know you're not suggesting we get rid of it. My point was that **as
an action at a distance** setting controlling the exception handling
behaviour, we might well want to phase it out at some point in the fut
It was the **action at a distance** nature of it that I thought you would
equally to me not be keen on.
The point I (really!) imagined that we'd just agree on is that **action at
a distance** type code is to be avoided. (Hence my use if "horrific" —
using humour as I didn't think it a point where we wouldn't already
agree.)
So the relevance for your suggestion here is that I don't think **an
action at a distance** use of a setting to control the behaviour of the
test client is a good move. Rather, setting a flag on the test client —
the `raise_request_exceptions` flag — is the right locus for this
behaviour.
As I say, I really thought this would be something you just agreed with.
(Action at a distance **is** horrible right? 🙂)
Then...
> Ultimately, my goal is to have the test client not skip parts of the
Django request/response stack by default.
This I understand. It's totally reasonable. (I'm not sure I agree yet but
I understand the desire.)
For me, the way to do this, if we want it, is to swap the default
behaviour (i.e. change `raise_request_exceptions` from `True` to `False`)
So, can we agree that far? (That's a genuine question.)
Then it's "should we switch the default?" And, "is there another way to
achieve similar?" One existing way would be to set `client_class` on the
TestCase to return a suitably configured client.
--
Ticket URL: <https://code.djangoproject.com/ticket/30249#comment:6>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.c2f9dd4dc7f7b4f3943a8062df0f00df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
