Opened 12 years ago

Closed 12 years ago

#18395 closed Bug (fixed)

Make a brittle i18n test more reliable

Reported by: Julien Phalip Owned by: nobody
Component: Internationalization Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

While working on #18393, I've noticed that if the try/except clause was removed from the blocktrans tag's code (which was introduced in https://github.com/django/django/commit/16bb9c594c), then the test i18n.TranslationTests.test_bad_placeholder would correctly fail if run on its own, however there would be no failure if running the entire i18n suite. I'm not sure why that is at this stage.

While nothing is broken per-se right now, the test is too brittle and may not catch regressions when the entire test suite is run. So the test should be made more reliable.

Attachments (1)

18395-1.diff (686 bytes ) - added by Claude Paroz 12 years ago.
Reset translation global variables with setting_changed

Download all attachments as: .zip

Change History (6)

comment:1 by Ramiro Morales, 12 years ago

The problematic test seems to be regressiontests.i18n.contenttypes.ContentTypeTests.test_verbose_name()

The problem persists if you comment the translation.override('en') call, if comment the translation.override('fr') call things work as expected.

Also, if you run both methods in the reverse order things work as expected in i18n.TranslationTests.test_bad_placeholder but fail in test_verbose_name() like if no French translation was installed:

======================================================================
FAIL: test_verbose_name (regressiontests.i18n.contenttypes.tests.ContentTypeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ramiro/django/git/tests/regressiontests/i18n/contenttypes/tests.py", line 28, in test_verbose_name
    self.assertEqual(unicode(company_type), u'Société')
AssertionError: u'Company' != u'Soci\xe9t\xe9'
- Company
+ Soci\xe9t\xe9

All this seem to point to a problem when there are two calls to translation.override('xx) with the same value of 'xx' in the same test run (thread/process), the second one has no effect. Maybe the underlying django.utils.translation.activate('xx') function has this limitation?

comment:2 by Ramiro Morales, 12 years ago

Maybe we need to munge with the internals of trans_real (_active, _translations) like it is already done in other tests in the same file?.

Or better yet, create testing tools that allow to flush that kind of cached values as it has been discussed a few times already.

comment:3 by Claude Paroz, 12 years ago

Has patch: set

Ramiro, I suspect we are reaching here the same issue described in ticket:17980#comment:15 (trans_real._default caching). In your specific case, the problem is maybe more related to _translations caching than _default. When LOCALE_PATHS setting is changed, the _translations global dictionary should probably be reset.

by Claude Paroz, 12 years ago

Attachment: 18395-1.diff added

Reset translation global variables with setting_changed

comment:4 by Jannis Leidel, 12 years ago

Triage Stage: AcceptedReady for checkin

comment:5 by Claude Paroz <claude@…>, 12 years ago

Resolution: fixed
Status: newclosed

In [32a4df6c55f2efd020b7fbc44c858f61b07da17d]:

Fixed #18395 -- Reset language-related global variables with setting_changed

Note: See TracTickets for help on using tickets.
Back to Top