django.contrib.auth.tests fail with custom Authentication Backends

[Tim Child]

When you are using custom Authentication backend the tests in django.contrib.auth.tests.test.FORM_TESTS fail.

FAIL: Doctest: django.contrib.auth.tests.__test__.FORM_TESTS
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/test/_doctest.py", line 2180, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for django.contrib.auth.tests.__test__.FORM_TESTS
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/auth/tests/__init__.py", line unknown line number, in FORM_TESTS

----------------------------------------------------------------------
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/auth/tests/__init__.py", line ?, in django.contrib.auth.tests.__test__.FORM_TESTS
Failed example:
    form.is_valid()
Expected:
    False
Got:
    403: Forbidden
    Context: user
    False

These should obviously not fail, but it would be preferable for a way to override them.

[Tim Child]

The offending test is:

{{{ # The user submits an invalid username.

data = {

... 'username': 'jsmith_does_not_exist',
... 'password': 'test123',
... }

form = AuthenticationForm(None, data)
form.is_valid()

False

form.non_field_errors()

[u'Please enter a correct username and password. Note that both fields are case-sensitive.']

}}}

[Russell Keith-Magee]

This is another example of the wider problem of "integration vs application tests". The test's dependence on an external setting environment means that local application conditions can make the test fail.

Yes, it's annoying, but it's not alone. There are a couple of other places where similar test failures occur. We need address the general problem, but it not critical for 1.2.

[mattjmorrison]

changed some django.contrib tests to explicitly define which middleware classes and authentication backends are assumed to be in settings.

[Julien Phalip]

See also #17194.

[Claude Paroz]

Use a new DefaultSettingsTestCase

[Claude Paroz]

I'm resubmitting the (refreshed) patch that I proposed for #17194, with the idea of a DefaultSettingsTestCase to isolate the app tests from any current project settings.

[Tim Graham]

This seems like a good idea to me; patch needs to be updated to apply cleanly though.

#20796 was a recent a duplicate.

[Russell Keith-Magee]

Isn't this a moot point once 1.6 lands? Django's new unittest discovery mechanism means that auth tests won't be run as part of an end-developer's test suite, so the we don't have to be quite as concerned about adapting to every possible environmental configuration.

[Tim Graham]

Ah, didn't realize that Russ, thanks!