In Django tests, how do override_settings and modify_settings differ, and when do you reach for each?

## Two tools for one job Django tests often need a configuration that differs from the project's `settings.py`: another `LOGIN_URL`, an extra middleware, an app missing from `INSTALLED_APPS`. The `django.test` package ships two helpers for this, and both undo themselves when the test or block ends. - **`override_settings(**kwargs)`** replaces the *whole value* of each named setting. `@override_settings(LOGIN_URL='/other/login/')` makes `settings.LOGIN_URL` return `'/other/login/'` until the override exits. - **`modify_settings(**kwargs)`** edits *list-valued* settings such as `MIDDLEWARE` or `INSTALLED_APPS`. Instead of retyping the list, you describe a delta with the actions `append`, `prepend` and `remove`. The rule of thumb: use `override_settings` for scalars, dicts and whole-list replacement; use `modify_settings` when the test only cares that one or two entries are present or absent, so the test keeps working when someone adds a middleware to the project list next month. ## Three ways to apply them | Form | Where the override is active | Typical use | |---|---|---| | Method decorator `@override_settings(...)` | only while that test method runs | one test needs one value | | Class decorator on a `SimpleTestCase` subclass | from `setUpClass` on: `setUpTestData`, `setUp` and every test | a whole class shares the configuration | | Context manager `with self.settings(...)` or `with self.modify_settings(...)` | inside the `with` block | before/after comparisons inside one test | Two details trip people up. First, a method decorator wraps only the test method, and unittest calls `setUp()` *before* that method, so `setUp()` still sees the original value. Second, the class decorator accepts only a subclass of Django's `SimpleTestCase` (which includes `TestCase` and `TransactionTestCase`); decorating a plain `unittest.TestCase` raises `ValueError`. The class decorator modifies the class in place instead of returning a copy, and when both decorators sit on one class, `modify_settings` is applied after `override_settings`. ## How modify_settings reads its actions Each keyword is a setting name mapped to a dict of actions: 1. `append` adds items to the end of the list, skipping any that are already present. 2. `prepend` adds items to the front, again skipping items already present, and keeps the order you gave. 3. `remove` drops matching items; removing something that is not in the list does nothing. 4. Each action takes a single string or a list of strings; any other action name raises `ValueError`. The starting point is the setting's *current* value, so a method-level `modify_settings` stacked on a class-level one composes the two edits. ## What happens under the hood Neither helper touches your settings module. `override_settings` wraps the live settings object in a temporary holder that answers the overridden names and falls through to the original for everything else, swaps it in, and swaps the original back on exit. For every overridden name it sends the **`setting_changed`** signal (defined in `django.core.signals`, documented as `django.test.signals.setting_changed`) with `enter=True`, and again with `enter=False` on exit. Django's own receivers use it to discard state computed from settings, for example: - `TEMPLATES` resets the template engines; - `CACHES` closes and rebuilds the cache handlers; - `ROOT_URLCONF` clears the URL resolver caches; - `PASSWORD_HASHERS` clears the cached list of hashers; - `INSTALLED_APPS` is applied to the app registry before the new values take effect. ## Where an override does not reach The mechanism works only for code that reads `django.conf.settings` *at the moment it needs the value*. It misses these cases: - **Module-level aliases** such as `SENDER = settings.DEFAULT_FROM_EMAIL` are evaluated once, at import, so the override never reaches them. - **Your own caches** derived from a setting (an `lru_cache` function, a class attribute built at import) keep the old value unless you connect a `setting_changed` receiver that clears them. - **Settings consulted only at startup** change on the settings object but not inside Django's internals; the docs advise against overriding `DATABASES` at all. - **Direct assignment** such as `settings.DEBUG = True` inside a test is never restored and leaks into every later test in the process. To simulate a missing setting, apply `@override_settings()` with no arguments and `del settings.LOGIN_URL` inside the test; the deletion happens on the temporary holder and disappears with it. ## What interviewers listen for A strong answer names both helpers, shows the three application forms, explains the `append`/`prepend`/`remove` no-op rules, and gives at least one way an override fails to reach code — the module-level constant is the classic example.