Auth tests failing on non-US locales

[Henrique C. Alves]

Auth tests are failing on current trunk (1.4). An error message is being compared as a test condition, but this fails since the error message will return a translated string (in this particular case, pt_br).

Destroying old test database 'default'...
..........F
======================================================================
FAIL: test_inactive_user (django.contrib.auth.tests.forms.AuthenticationFormTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/hcalves/.virtualenvs/omelete.v2/src/django/django/contrib/auth/tests/forms.py", line 105, in test_inactive_user
    [u'This account is inactive.'])
AssertionError: [u'Esta conta est\xe1 inativa.'] != [u'This account is inactive.']

[Julien Phalip]

That's right, multiple tests are failing when the project's settings.LANGUAGE_CODE isn't English. Those tests need to be made more isolated by temporarily overriding the locale. Would you like to provide a patch?

[Claude Paroz]

Fix language isolation of contrib.auth tests

[Claude Paroz]

Here's my proposal to fix it. Just setting LANGUAGE_CODE isn't sufficient to change current language, that's why I changed override_settings to special-case LANGUAGE_CODE setting change. Might be useful in other tests, too.

The other solution would be to enclose each string comparison test with translation.override, but it seems not very DRY to me.

[Claude Paroz]

Add middleware isolation for test_session_not_accessed

[Claude Paroz]

Alternate approach with DefaultSettingsTestCase

[Claude Paroz]

After discussion with Julien on irc, I've come with a radically different approach, with a new DefaultSettingsTestCase class that strives to completely isolate the contrib.auth tests from custom project settings.

[Claude Paroz]

Note also that the latest patch might also fix #13394 and #16366. (see also #9156)

[Henrique C. Alves]

The patch only overrides the locale for Django's own tests, correct? User-provided tests will still run on the settings.py locale?

[Claude Paroz]

Replying to hcarvalhoalves:

The patch only overrides the locale for Django's own tests, correct? User-provided tests will still run on the settings.py locale?

Yes, of course.

[Jannis Leidel]

Hm, I'm not sure why another test case class is needed, mind elaborating? I always thought @override_settings and self.settings() would be enough, isolating test classes has worked elsewhere, so why shouldn't it here?

[Claude Paroz]

With @override_settings and self.settings(), the logic is "Current settings except this one and this one". You never really no if suddenly a new different setting has a new side effect.

With this class, the logic is reversed. Default settings are the base (sort of a sandbox), and you only specify the particular settings (if any) which you want to specifically test.

There are pros and cons, as usual. The DefaultSettingsTestCase approach does address the specific issue of being able to test with a known and stable set of settings. Whether it is wanted or not, that's a design decision.

[rabio]

Let me propose another approach. Instead of setting fixed locale for auth tests, use localized strings in tests instead. Patch attached below does exactly that.

[rabio]

Another approach: localize strings in tests instead of setting fixed locale

[Bas Peschier]

If you go that approach, it might be a good idea to actually place the error messages on the relevant forms and fields so you can reuse them in the tests.

It's also better to reuse the html-escape from django (in django.utils.html) instead of creating a new one.

Attached a patch.

[Jannis Leidel]

In [17204]:

Fixed #17194 -- Made sure the auth form tests work if a language other than English is activated by moving the error message translation strings into class level dictionaries. Many thanks to Claude Paroz, rabio and Bas Peschier for their initial work on this.