Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики  

На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.

В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.

🛠️ Внешние сервисы без тестовых контуров

Решение: собственный мок-сервис на основе WireMock.

Как он работает:

• тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;

• нужные вызовы подменяются в конфигурации;

• при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.

Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.

Плюс: так мы не зависим от внешних API, которые то работают, то нет.

💸 Платные вызовы и лимиты на тестовые запросы

Решение: изолированные стенды и замещение моками везде, где возможно.

Если API-партнер дает 150 вызовов в месяц, а вам нужно 500 на автотесты — моки опять же спасают. Мы блокируем обращения к реальным API на командных стендах и заменяем их заглушками. Проверку живых интеграций оставляем только на пред-проде.

Плюсы:

• не сжигаем бюджет;

• эмулируем ошибки и нестандартные ответы;

• ускоряем тесты без зависимости от внешней стороны.

🔄 Нестабильность интеграционных тестов

Решение: изоляция и моки как защитный слой.

Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:

• эмулируем нестабильные вызовы моками;

• изолируем свою часть и фокусируемся на ее стабильности;

• прогоняем тесты на командных стендах — быстро, стабильно и без флуктуаций от партнеров.

🤝 Десятки команд, завязанных на общий процесс

Решение: интеграционные проверки и ревью на совместимость.

Когда много команд делают один продукт, любое изменение может зацепить чужой модуль. Мы выстроили систему так, чтобы ошибки ловились до мерджа, а не после инцидента. Что помогло:

• общие тестовые фреймворки и единый подход к интеграционным тестам;

• сценарии, которые включают зависимости от других команд;

• проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.

Подробнее о каждом из подходов читайте в статье QA-инженера AGIMA Святослава Волохова.