Integration tests still reading production credentials despite override_settings in Django

Goal

I want a reliable way to run Django integration tests that exercise code paths normally talking to external services (email, cache, payment or storage APIs) without ever loading production credentials. The project currently relies on environment variables for secrets, and the test suite uses override_settings in places, but there is no enforced project-wide convention for keeping real secrets out of test runs.

Constraints and uncertainty

Some third-party apps appear to read configuration at module import time, so swapping settings after django.setup() may be too late to stop them from capturing real values. CI jobs may also export production secret variables into the same shell that runs tests, and libraries that resolve settings lazily could pick those up. The team is undecided between three approaches: a dedicated test settings module selected via DJANGO_SETTINGS_MODULE, per-test override_settings decorators, or built-in credential-free stand-ins such as the locmem email backend and dummy cache.

Assume a current Django LTS release; settings-loading and test-runner initialization details may differ across versions.

Questions

• Which isolation point guarantees no module sees production secrets: a separate settings module loaded before setup, or decorator-based overrides?
• How can a test run verify that no real network connection or real credential was used?
• Is there a documented pattern for preventing CI-exported secret variables from leaking into the test process?