Зачем для тестов используют отдельные конфигурации и переменные окружения (например, отдельный .env.test), а не те же настройки, что и для разработки или production?

Короткий ответ

Отдельная тестовая конфигурация нужна, чтобы тесты всегда запускались с предсказуемыми, безопасными значениями (адрес тестовой БД, отключённая отправка реальных писем, тестовые ключи внешних сервисов) и не зависели от того, что случайно настроено на машине разработчика или в production.

Как это работает подробнее

Приложение обычно читает настройки из переменных окружения или конфигурационного файла; для тестового прогона эти значения переопределяются отдельным файлом (например, .env.test) или фикстурой pytest, которая выставляет переменные окружения перед тестами и возвращает их к исходным значениям после завершения прогона.

Пример кода

testing_example_306.yamlКопировать

# .env.test
DATABASE_URL=postgresql://test_user:test_pass@localhost:5433/test_db
MAIL_BACKEND=console   # письма не отправляются реально, а печатаются в лог
PAYMENT_GATEWAY_KEY=test_sandbox_key_0000

Что использовать на практике

• Практика. Важно, чтобы тестовая конфигурация явно указывала на тестовую БД, тестовый (или замоканный) внешний сервис и безопасные заглушки для секретов — ни один тестовый прогон не должен иметь технической возможности случайно отправить реальное письмо или списать реальные деньги через production-ключ, даже при ошибке в коде теста.

Подводные камни

• Риск. Запускать тесты с конфигурацией по умолчанию, которая на самом деле указывает на БД для локальной разработки — тесты незаметно портят или удаляют данные, которые разработчик использовал руками. Хранить реальные production-секреты в тестовой конфигурации «для удобства», что создаёт риск их утечки через тестовые логи, отчёты CI или историю коммитов.