Code

Opened 4 years ago

Closed 3 months ago

#12571 closed Bug (fixed)

Test client doesn't set WSGIRequest instance on response

Reported by: rvdrijst Owned by: unaizalakain
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

Description

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 4 years ago.
adds the wsgi_request to the client response

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by rvdrijst

adds the wsgi_request to the client response

comment:1 Changed 4 years ago by russellm

  • milestone 1.2 deleted
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted
  • Version SVN deleted

comment:2 Changed 4 years ago by SmileyChris

  • Needs documentation set
  • Needs tests set

comment:3 Changed 3 years ago by mattmcc

  • Severity set to Normal
  • Type set to Bug

comment:4 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:6 Changed 5 months ago by unaizalakain

This would solve the problems mentioned in https://code.djangoproject.com/ticket/15179#comment:24

comment:7 Changed 5 months ago by unaizalakain

  • Owner changed from nobody to unaizalakain
  • Status changed from new to assigned

comment:8 Changed 5 months ago by unaizalakain

  • Needs documentation unset
  • Needs tests unset
  • Version set to master

comment:9 Changed 3 months ago by timo

  • Triage Stage changed from Accepted to Ready for checkin

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

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.