Test client doesn't set WSGIRequest instance on response
|Reported by:||rvdrijst||Owned by:||Unai Zalakain|
|Severity:||Normal||Keywords:||test client request response WSGIRequest|
|Cc:||rvdrijst@…||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
When you call
post() on the
Client instance in a testcase, the returned response contains a
request attribute that is a simple
dict created by the client to simulate a request. This can be useful, but it is not the request instance that is used in views and middleware.
It would be very useful to have the request instance as seen (and possibly modified) by the view and middleware. This is the
WSGIRequest instance created in the
ClientHandler, used by the
Client. This instance is based on the simple
dict that is currently set on the response as the request.
I came across this problem before and worked around it, but now with the new messages framework, a clear usecase presents itself. You cannot get to the messages set by a tested view, simply because the
response.request is not the
WSGIRequest instance that was used for setting the messages.
A (backwards compatible) solution is to let the
ClientHandler add this
WSGIRequest instance as an attribute called
wsgi_request to the
response before it returns it.
Using this solution, you can get to the message storage by doing
messages.get_messages(response.wsgi_request). It can also be useful for testing middleware, decorators and other functionalities that modify the request in any way.
Attached is the extremely simple patch that makes this one-line addition.
Change History (11)
comment:1 Changed 7 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Accepted|