Add a "redirect_to" attribute (similar to status_code) to HttpResponseRedirect and HttpResponsePermanentRedirect to help with testing

[egmanoj@…]

Consider this test:

response = self.client.post(url, params)

self.failUnlessEqual(response.status_code, 302)
self.failUnlessEqual(response.headers['Location'], some_other_url)

It would be easier to do the following instead, treating redirect_to as an attribute.

self.failUnlessEqual(response.redirect_to, some_other_url)

[egmanoj@…]

Diff of django/http/init.py

[Chris Beaven]

Looks good, could probably do with some docs

[egmanoj@…]

Replying to SmileyChris:

Looks good, could probably do with some docs

I am not sure how to go about adding the necessary documentation.
Any guidance would be appreciated.

Thanks,
Manoj

[egmanoj@…]

Documentation for the suggested code change for HttpResponseRedirect and HttpResponsePermanentRedirect.

[Malcolm Tredinnick]

I don't think this is worth it. Firstly, it's a core change just for tests and for something you can already do. Secondly, you would still need to test that it's some kind of redirect, because redirect_to will only be on certain types of responses.

Finally, assertRedirect() seems to already provide a handy helper for all this.

[Manoj Govindan <egmanoj@…>]

assertRedirect() requires tests to be derived from django.test.TestCase, something that slows down test execution considerably. There is also the ​known problem with assertRedirect() that messes up tests.

[Malcolm Tredinnick]

Those are things that can be fixed in other ways and should be directed at the appropriate tickets and components. Adding a new attribute to a core data structure that is only used by the test suite and is to work around limitations in the test framework (#5538 isn't even a limitation; it's just asking for a shortcut) is poor design. Plus you can already accomplish what you need here.

Please don't reopen. The goal is always to fix the root problems, not add workarounds.