django password reset tests assume hardcoded urls

[teh]

in django/contrib/auth/tests/views.py there are lines like e.g.:

response = self.client.post('/password_reset/', {'email': 'not_a_real_email@email.com'})

When one associates the password views with different urls in urls.py these tests will fail because of the hardcoded '/password_reset/'.

[Jacob]

Not a 1.0 bug.

I'm actually not sure if it's a bug at all -- we can't anticipate every possible test environment in the test suite -- but I suspect in this particular case we should be doing something different.

[anonymous]

We could use a reverse lookup to check which URL to use for testing

reverse('django-password-reset') 

If the user hasn't named his URL then we fall back to the normal '/password_reset/'

[Chris Beaven]

It's a valid bug, and one which has actually irked me for quite a while.

The problem is due to the now loudly failing {% url %} tag. If you override a registration template with one which uses a URL tag, you'll end up with your project tests failing loudly for tde contrib.auth tests.

I think the solution would be to put default templates in the contrib/auth/tests/template dir (I'm assuming this gets used somehow but didn't see the code which activates this).

[Chris Beaven]

(ah, I see now that it does it specifically for views.ChangePasswordTests. So, would also need to abstract that code to work with all the contrib tests.

[Chris Beaven]

Hrm... looking at the original issue, I realize that I have hijacked this ticket with a separate issue (test failures due to overridden templates). Ignore the attachment, I'm putting this back to design decision where I found it.

[Chris Beaven]

New ticket opened as #10818

[Chris Beaven]

Assigning to myself to have a look at whether this is still an issue (but if someone wants to jump in and confirm it before I get the chance to do that, feel free) :)

[Mark Lavin]

While the urls are hard coded the testcase, the testcase also defines the urls in AuthViewsTestCase. I'm not convinced there is (still) a bug here.

[Aymeric Augustin]

I agree with mlavin — since the test cases set urls = '...', having hardcoded URLs is fine. I just checked that all auth tests do.

It seems that the original report was based on code inspection, not on an actual problem — there is not traceback or test run output.