Document that setting language in tests affects other tests

[Václav Řehák]

The testing documentation ​https://docs.djangoproject.com/en/4.1/topics/testing/tools/#setting-the-language suggests to set language in tests using a cookie or http header. But it is not obvious to the reader that doing so will switch the Django active language for all other subsequent tests.

In our case we had random test failures in parallel run depending on the actual order of tests executed. This is easily reproducible with the following test file

from django.contrib.auth.forms import AuthenticationForm
from django.test import TestCase

class ViewTestCase(TestCase):
    def test_czech_request(self):
        self.client.get("/", HTTP_ACCEPT_LANGUAGE="cs-cz")


class FormTestCase(TestCase):
    def test_form(self):
        f = AuthenticationForm(data={})
        self.assertEqual(f.errors['username'], ['This field is required.'])

This testsuite passes in normal run (form is tested before the view) but fails when running tests with --reverse as the view test switches Django to Czech language and the validation errors of the form are translated.

I'm not sure if this can be fixed (should the test runner activate the default language before each test?) but I suggest to at least document it and probably recommend the user to activate the default language in tearDown method.

    def tearDown(self):
        translation.activate(settings.LANGUAGE_CODE)

[Carlton Gibson]

Yes, this reproduces. Thanks!

Expected behaviour was doc'd in 3c447b108ac70757001171f7a4791f493880bf5b.

I wonder if this is a regression somewhere? (Update: but it's the same behaviour on stable/3.2.x)

It would be good to resolve as not merely a docs fix, since otherwise the override method (not using the LocaleMiddleware would be the only really feasible way.)

[Carlton Gibson]

#34181 was a duplicate which found source of this behaviour:

Django's LocaleMiddleware only activates a translation, but doesn't deactivate it since #5241 / ​
​https://github.com/django/django/commit/aa089b106b6cfc9a47cd54a0f9eb44bd44811ed9.

Given that this was for Django 1.6, ≈9 years ago now, I think we can consider it established behaviour.
(Again, I think a note in the docs is likely option 1.)

[Raphaël Barrois]

I'll add the results of the extra investigation I did in #34181 (sorry for not seeing this ticket, it wasn't here when I started writing mine 😅):

• The issue happened with the fix for #5241 in ​https://github.com/django/django/commit/aa089b106b6cfc9a47cd54a0f9eb44bd44811ed9
• Django's LocaleMiddleware no longer calls translation.deactivate() as part of its request cleanup.

However, the pattern shown here is very close to typical code used in tests, where strings marked for translation are tested against the value in the default locale.

I feel that a documentation fix stating "Every test asserting on a string marked for translation should wrap said assertion with translation.override" wouldn't actually help users, as that would add a significant amount of boilerplate to test cases.

If the recommended solution is to call translation.deactivate() in each test case' tearDown, I'd suggest including that in Django's source code.
Another option could be for the test client to deactivate translations post-request when it detects that the LocaleMiddleware is enabled.
Otherwise, we could also explore the possibility to restore the locale context in some post-request handler, server-side.

[Václav Řehák]

To fix this at the moment, we will be adding translation.deactivate() to the base class of our tests. I wonder if there is any downside of including this in Django's TestCase tearDown. I'm not fan of keeping the current behavior as it can lead to difficult-to-debug random failures of tests.

[Faris Naimi]

The documentation was modified to explain the issue and the possibility of activating the default language in the tearDown method.

This is now available from the branch "ticket_34180" on the repo:

​https://github.com/fnaimi66/django.git

[Václav Řehák]

How can you close ticket just because there is a commit in a Github fork? The issue is not closed until is it merged into Django source code (or wontfixed).

[Tim Graham]

​PR

[Carlton Gibson]

PR looks OK. Just needs tweaks.

[Mariusz Felisiak]

​New PR

[Mariusz Felisiak <felisiak.mariusz@…>]

In 40217d1:

Fixed #34180 -- Added note about resetting language in test tear-downs.

Co-authored-by: Faris Naimi <farisfaris66@…>

[Mariusz Felisiak <felisiak.mariusz@…>]

In af396ce:

[4.2.x] Fixed #34180 -- Added note about resetting language in test tear-downs.

Co-authored-by: Faris Naimi <farisfaris66@…>

Backport of 40217d1a82b0c16cddba377325d12b2c253f402a from main

[Mariusz Felisiak <felisiak.mariusz@…>]

In f586c12f:

[4.1.x] Fixed #34180 -- Added note about resetting language in test tear-downs.

Co-authored-by: Faris Naimi <farisfaris66@…>

Backport of 40217d1a82b0c16cddba377325d12b2c253f402a from main