Средний ~25 мин чтения

Интеграционные тесты: API, БД и внешние сервисы

Урок 3 из 5 в курсе Тестирование backend-приложений

Интеграционные тесты: API, БД и внешние сервисы

интеграционные тесты проверяют взаимодействие компонентов — HTTP endpoint + controller + сервис + БД — в реалистичном окружении

Почему это важно: unit-тесты не проверяют SQL-запросы, HTTP-маршрутизацию и сериализацию. Интеграционные тесты находят ошибки на стыках компонентов

Главная идея

тестируем API как чёрный ящик: POST /users → 201, тело ответа, запись в БД. Это именно то, что делает клиент

Как это выглядит на практике

  1. Тест: POST /api/v1/users с валидными данными → ожидаем 201 и JSON с id.
  2. Тест: POST /api/v1/users без email → ожидаем 422 и error message.
  3. Тест: GET /api/v1/posts — проверяем что возвращаются только опубликованные посты.
  4. Database cleaner: откатываем транзакцию после каждого теста; БД чиста.
  5. Factory/fixture: создаём тестовые данные декларативно (FactoryBot, factory_boy).

Что происходит под капотом

  • Transaction rollback strategy: тест обёрнут в транзакцию, которая откатывается; быстрее удаления записей.
  • Test database: отдельная БД для тестов; никогда не mixing с development/production.
  • VCR (cassettes): записываем реальные HTTP-ответы внешних сервисов и воспроизводим в тестах.
  • Contract testing (Pact): проверяем, что наш API соответствует ожиданиям потребителя.

Типичные ошибки и заблуждения

  • Ошибка: интеграционные тесты медленные — нужно избегать. Медленные интеграционные тесты — сигнал оптимизировать setup, а не отказываться от тестов.
  • Ошибка: тестировать каждый SQL-запрос отдельно. Тестируй поведение через публичный API; SQL — деталь реализации.
  • Ошибка: моки внешних сервисов не нужны — будем использовать реальные. Нестабильные внешние сервисы делают тесты flaky; используй VCR или WebMock.
  • Ошибка: одна тестовая БД на всех разработчиков. Каждый разработчик — отдельная тестовая БД, или параллельные схемы.

Ключевые выводы

  • Тестируй API как чёрный ящик: вход → выход → побочные эффекты.
  • Изоли внешние сервисы: WebMock, VCR, WireMock.
  • Тестовые данные через factories, не хардкод.
  • Transaction rollback — быстрее full cleanup.

Термины урока

Integration test: тест взаимодействия нескольких компонентов системы.
Factory (FactoryBot): декларативное создание тестовых объектов.
Database Cleaner: инструмент очистки БД между тестами.
VCR: запись и воспроизведение HTTP-взаимодействий в тестах.
Contract test: проверка соответствия API контракту, ожидаемому потребителем.

Связь с работой backend-разработчика

Каждый API-эндпоинт должен иметь минимум 3 интеграционных теста: happy path, validation error, unauthorized. Это даёт базовую уверенность в правильности API.

Мини-разбор реальной ситуации

Миграция БД добавляет NOT NULL ограничение на поле. Unit-тесты зелёные — они не работают с реальной БД. Интеграционные тесты падают: INSERT нарушает constraint. Баг найден в тестах, а не в продакшене.

Что запомнить

  • Интеграционные тесты находят баги на стыках компонентов.
  • Используй transaction rollback для скорости.
  • Изолируй внешние зависимости: VCR, WebMock.

Итог

Интеграционные тесты — это документация API через код. Они дают уверенность, что компоненты работают вместе, а не только по отдельности.