#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):


 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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to