Integration tests still reading production credentials despite override_settings in Django

The Isolation Point

To guarantee that no module sees production secrets, you must use a separate settings module selected via DJANGO_SETTINGS_MODULE. Decorator-based overrides (@override_settings) are insufficient for this goal because they apply only during the execution of the decorated function.

Why override_settings Fails for Secrets

Many third-party libraries and some Django AppConfig implementations read configuration at the module level during the initial import phase. By the time django.setup() is called and your tests begin executing, these libraries have already captured the production values from the environment or the default settings file. Because override_settings modifies the settings object at runtime, it cannot "undo" a value that has already been cached in a third-party module's internal state.

Implementation Steps for Total Isolation

1. Create a settings_test.py: Define all secrets as dummy values or use built-in stand-ins (e.g., EMAIL_BACKEND = 'django.core.mail.backends.locmem.LocMemEmailBackend' and CACHES = {'default': {'BACKEND': 'django.core.cache.backends.locmem.LocMemCache'}}).
2. Force the Module: Execute your tests by explicitly setting the environment variable:

   export DJANGO_SETTINGS_MODULE=myproject.settings_test
   python manage.py test

3. Sanitize the CI Shell: To prevent CI-exported variables from leaking into the process, use a wrapper script or a sanitized shell command to unset sensitive keys before the test runner starts:

   unset PROD_API_KEY PROD_DB_PASSWORD && python manage.py test

Verification Methods

To verify that no real credentials or network connections are being used, implement the following checks:

• Environment Audit: Add a temporary test case that asserts os.environ does not contain production keys.
• Network Interception: Use a library like responses or httpretty to intercept all outbound HTTP requests. If a test attempts to hit a production API endpoint, the interceptor will trigger a failure.
• Log Inspection: Check for "Connection Refused" or "Authentication Failed" errors in your test logs, which often indicate a library is attempting to use a dummy credential against a real endpoint.

Diagnostic Detail

Are any of your third-party libraries calling os.environ.get() directly instead of accessing django.conf.settings? If so, changing the settings module will not be enough; you must explicitly unset those variables in the shell before running tests.