Как ускорить прогон интеграционных тестов?

Интеграционные тесты проверяют взаимодействие нескольких компонентов: приложения с базой данных, брокером сообщений, внешними API. Именно из-за реальных зависимостей они в разы медленнее юнит-тестов, и на больших проектах прогон может занимать десятки минут. Задача — сохранить достоверность проверки, но убрать лишние накладные расходы.

Основные приёмы ускорения

• Параллельный запуск. Разделите тесты на независимые группы и запускайте их в нескольких потоках или процессах. В JUnit 5 это делается через junit.jupiter.execution.parallel.enabled=true, в pytest — через pytest-xdist.
• Переиспользование инфраструктуры. Поднимайте контейнеры (Testcontainers, Docker Compose) один раз на весь набор тестов, а не на каждый класс. Это экономит секунды на старте БД и брокеров.
• Транзакционный откат. Вместо пересоздания схемы перед каждым тестом оборачивайте его в транзакцию и откатывайте в конце. Так состояние БД изолировано, а DDL не выполняется повторно.
• Моки внешних сервисов. Реальные сторонние API заменяйте на WireMock, MockServer или локальные заглушки — сеть и лимиты не тормозят прогон.
• Умный выбор тестов. Запускайте только те, что затронуты изменениями (test impact analysis), а полный набор — по расписанию ночью.

Пример: параллельный pytest с переиспользуемой БД

# conftest.py
import pytest
from testcontainers.postgres import PostgresContainer

@pytest.fixture(scope="session")
def postgres():
    with PostgresContainer("postgres:16") as pg:
        yield pg.get_connection_url()

@pytest.fixture(autouse=True)
def rollback(db_conn):
    tx = db_conn.begin()
    yield
    tx.rollback()

# запуск: pytest -n auto --dist loadscope

Здесь контейнер поднимается один раз на сессию, а каждый тест работает в своей транзакции и откатывает её. Флаг -n auto распределяет тесты по ядрам CPU.

Что даёт эффект на практике

Комбинация параллелизма, переиспользования контейнеров и транзакционных фикстур обычно сокращает время прогона в 3–10 раз. Дополнительно стоит кэшировать зависимости в CI, использовать быстрые in-memory аналоги (например, SQLite для простых сценариев) и выносить самые тяжёлые end-to-end тесты в отдельный ночной пайплайн.

Итог: ускорять интеграционные тесты стоит через параллельный запуск, общую инфраструктуру и изоляцию состояния — это сохраняет достоверность проверок и возвращает быструю обратную связь в CI.