Зачем для тестов нужна отдельная тестовая база данных и как её обычно подключают в проекте?

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

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

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

Тестовая БД может быть отдельной базой в том же СУБД-инстансе, временным SQLite-файлом или контейнером, поднятым специально для тестового прогона (например, через testcontainers или docker-compose), и полностью независима от БД разработки. Фикстура уровня сессии обычно применяет миграции один раз в начале прогона, а фикстура уровня функции очищает или откатывает данные между тестами.

Пример кода

testing_example_299.pyКопировать

import pytest
@pytest.fixture
def test_db():
    engine = create_engine("postgresql://test_user@localhost/test_db")
    Base.metadata.create_all(engine)
    yield engine
    Base.metadata.drop_all(engine)  # очистка после теста

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

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

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

• Риск. Использовать production БД для тестов «по привычке» или из экономии времени — это прямой риск порчи или удаления реальных данных пользователей. Не изолировать тесты друг от друга: один тест оставляет данные в таблице, которые влияют на результат следующего, из-за чего тесты начинают зависеть от порядка запуска и ломаются непредсказуемо.