Что такое интеграционное тестирование?
Интеграционное тестирование проверяет, как несколько компонентов работают вместе: приложение и база данных, сервис и внешнее API, два микросервиса между собой. Отдельно каждая часть может быть исправна, а на стыке всё равно возникнет ошибка.
Типичные дефекты этого уровня — как раз стыковочные: несовпадение форматов данных, изменившийся контракт API, неверная обработка ошибок соседнего сервиса, проблемы с транзакциями.
В отличие от модульных тестов, интеграционные запускают на реальных или близких к реальным зависимостях, поэтому они медленнее и сложнее в настройке. Их обычно меньше, но именно они ловят то, что не видно изнутри отдельного модуля.
Где применяется
Интеграционные проверки закрывают самые дорогие ошибки — те, что возникают на стыках. Приложение и база данных, сервис и платёжный шлюз, два микросервиса, обменивающиеся сообщениями: по отдельности каждая часть исправна, а вместе они расходятся в формате данных или в обработке ошибок.
В современных проектах такие тесты запускают на настоящих зависимостях, поднятых в контейнерах: реальная база вместо заглушки, локальный брокер сообщений, эмулятор внешнего API. Это медленнее модульных тестов, поэтому их обычно выделяют в отдельный этап конвейера.
Пример
Сервис заказов сохраняет сумму как целое число копеек, а сервис отчётов ожидает дробное значение в гривнах. Модульные тесты обоих проходят успешно — расхождение видно только в интеграционном тесте, где они обмениваются реальным сообщением.
Частые вопросы
Чем интеграционное тестирование отличается от модульного?
Модульный тест проверяет одну функцию в изоляции и подменяет все зависимости. Интеграционный проверяет несколько компонентов вместе, с настоящей базой или сервисом. Он медленнее и сложнее в настройке, но ловит ошибки, которые модульным тестам принципиально недоступны.
Нужна ли для таких тестов настоящая база данных?
Желательно та же, что в продакшене — иначе часть различий останется незамеченной. Стандартный сегодня подход: поднимать базу в контейнере на время прогона тестов. Это даёт реалистичность и при этом не требует общего стенда, который команда делит между собой.
Как тестировать интеграцию с внешним сервисом?
Чаще всего его подменяют управляемой заглушкой — сервером, который отвечает заранее заданными ответами, включая ошибки и таймауты. Так проверяется и штатное поведение, и реакция на сбой. Обращаться к реальному стороннему сервису в тестах рискованно и нестабильно.
Сколько интеграционных тестов нужно?
Заметно меньше, чем модульных: они дороже в поддержке и медленнее. Разумная стратегия — плотно закрывать логику модульными тестами, а интеграционными проверять ключевые связки и сценарии, где расхождение контрактов приведёт к реальным потерям.