Code

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#9159 closed Uncategorized (wontfix)

testing Client support for middleware

Reported by: hvendelbo Owned by: nobody
Component: Testing framework Version: 1.0
Severity: Normal Keywords: middleware testclient
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:

Description

I propose the following improvement:

The testing client is great for testing the whole request chain.
If you want to test the middleware part of the request, you need
to either,
1) Doing a regular request with an added middleware instance for
testing the request object.
2) Directly call one or more middleware instances passing a request
and response.

If your middleware sets a host_name attribute on the request object you can test it this way:

from django.test import Client,LastRequestMiddleware
...
def test_host_name(self):
    lrm = LastRequestMiddleware()
    c = Client(middleware_instances = [lrm])
    response = c.get('/')
    assert haskey(lrm.request,"host_name"), "The host name was not set"

Using this approach you can add any custom middleware to the chain.

If you want to test your middleware without relying on the url resolution and views
working, you can invoke a simplified handler that returns a blank response in place
of calling the view.

c = Client() 
mym = MyMiddleware()
response = c.get('/',only_middleware=[mym]) 
assert 'RESULT' in response, "RESULT header not added to response"

Calling the client this was means that the middleware classes from settings are not called,
but only the ones you specify by passing the list of instances.

Attachments (1)

django.test.patch (7.8 KB) - added by hvendelbo 6 years ago.
Patch without docs

Download all attachments as: .zip

Change History (4)

Changed 6 years ago by hvendelbo

Patch without docs

comment:1 follow-up: Changed 6 years ago by carljm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

There are a whole host of other settings besides MIDDLEWARE_CLASSES that one _might_ want to change temporarily for a test; adding them all as keyword args to the test client is ugly.

You can just change/set the actual setting and then revert after your test; see http://www.djangosnippets.org/snippets/1011/ for a snippet to make that easy.

Not resolving since I'm not a triager (someone higher up tell me if I should've just gone ahead and resolved this), but almost certain this is a wontfix.

comment:2 in reply to: ↑ 1 Changed 6 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

Replying to carljm:

Not resolving since I'm not a triager (someone higher up tell me if I should've just gone ahead and resolved this), but almost certain this is a wontfix.

Right on the money.

If you want to test middleware, test the middleware. A middleware is just two methods on a class; if you want to test the middleware, call those functions from your tests. Munging the entire test client to make it "easier" to invoke those methods is entirely the wrong way to go.

The only complication is that faking a request object to pass to the middleware method isn't completely trivial. The solution, therefore, is to make it easier to create a request object. #9002 contains a proposal for doing this that doesn't require so much duct tape.

On a completely procedural note - the patch also needs tests. As Malcolm noted in his DjangoCon talk - submitting a patch without tests is shorthand for "Here are some bugs I thought you should have". If you want your contributions to be taken seriously, write the tests first.

comment:3 Changed 3 years ago by anonymous@…

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized

[This comment has been deleted. Abusive comments aren't welcome here. -JKM]

Last edited 3 years ago by jacob (previous) (diff)

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.