modify_settings() [source]
Likewise, Django provides the modify_settings() decorator:
from django.test import TestCase, modify_settings
class MiddlewareTestCase(TestCase):
@modify_settings(MIDDLEWARE={
'append': 'django.middleware.cache.FetchFromCacheMiddleware',
'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
})
def test_cache_middleware(self):
response = self.client.get('/')
# ...
The decorator can also be applied to test case classes:
from django.test import TestCase, modify_settings
@modify_settings(MIDDLEWARE={
'append': 'django.middleware.cache.FetchFromCacheMiddleware',
'prepend': 'django.middleware.cache.UpdateCacheMiddleware',
})
class MiddlewareTestCase(TestCase):
def test_cache_middleware(self):
response = self.client.get('/')
# ...
Note
When given a class, these decorators modify the class directly and return it; they don’t create and return a modified copy of it. So if you try to tweak the above examples to assign the return value to a different name than LoginTestCase or MiddlewareTestCase, you may be surprised to find that the original test case classes are still equally affected by the decorator. For a given class, modify_settings() is always applied after override_settings().
Warning
The settings file contains some settings that are only consulted during initialization of Django internals. If you change them with override_settings, the setting is changed if you access it via the django.conf.settings module, however, Django’s internals access it differently. Effectively, using override_settings() or modify_settings() with these settings is probably not going to do what you expect it to do.
We do not recommend altering the DATABASES setting. Altering the CACHES setting is possible, but a bit tricky if you are using internals that make using of caching, like django.contrib.sessions. For example, you will have to reinitialize the session backend in a test that uses cached sessions and overrides CACHES.
Finally, avoid aliasing your settings as module-level constants as override_settings() won’t work on such values since they are only evaluated the first time the module is imported.
You can also simulate the absence of a setting by deleting it after settings have been overridden, like this:
@override_settings()
def test_something(self):
del settings.LOGIN_URL
...
When overriding settings, make sure to handle the cases in which your app’s code uses a cache or similar feature that retains state even if the setting is changed. Django provides the django.test.signals.setting_changed signal that lets you register callbacks to clean up and otherwise reset state when settings are changed.
Django itself uses this signal to reset various data:
| Overridden settings | Data reset |
|---|---|
| USE_TZ, TIME_ZONE | Databases timezone |
| TEMPLATES | Template engines |
| SERIALIZATION_MODULES | Serializers cache |
| LOCALE_PATHS, LANGUAGE_CODE | Default translation and loaded translations |
| MEDIA_ROOT, DEFAULT_FILE_STORAGE | Default file storage |
Please login to continue.