Opened 7 years ago

Closed 3 years ago

#12571 closed Bug (fixed)

Test client doesn't set WSGIRequest instance on response

Reported by: rvdrijst Owned by: Unai Zalakain
Component: Testing framework Version: master
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
Easy pickings: no UI/UX: no


When you call get() or 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.

Attachments (1)

test_client_request.diff (595 bytes) - added by rvdrijst 7 years ago.
adds the wsgi_request to the client response

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by rvdrijst

Attachment: test_client_request.diff added

adds the wsgi_request to the client response

comment:1 Changed 7 years ago by Russell Keith-Magee

milestone: 1.2
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted
Version: SVN

comment:2 Changed 7 years ago by Chris Beaven

Needs documentation: set
Needs tests: set

comment:3 Changed 6 years ago by Matt McClanahan

Severity: Normal
Type: Bug

comment:4 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:6 Changed 3 years ago by Unai Zalakain

This would solve the problems mentioned in

comment:7 Changed 3 years ago by Unai Zalakain

Owner: changed from nobody to Unai Zalakain
Status: newassigned

comment:8 Changed 3 years ago by Unai Zalakain

Needs documentation: unset
Needs tests: unset
Version: master

comment:9 Changed 3 years ago by Tim Graham

Triage Stage: AcceptedReady for checkin

comment:10 Changed 3 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In 9eb16031ca837624433c49646289b50f9566a25d:

Fixed #12571 -- Attached originating WSGIRequest to test client responses.

Originating WSGIRequests are now attached to the wsgi_request attribute of
the HttpResponse returned by the testing client.

Thanks rvdrijst for the suggestion.

Note: See TracTickets for help on using tickets.
Back to Top