Как спланировать стратегию тестирования функционала, затрагивающего несколько микросервисов
Что проверяют
Умеете ли вы строить тестирование от рисков и архитектуры, а не сводить всё к сквозным автотестам через интерфейс. Следом обычно спрашивают, как проверять асинхронное взаимодействие через очередь и что делать, когда один сервис недоступен.
Как отвечать
Начните с карты: какие сервисы участвуют, где синхронные вызовы (REST, gRPC), где события (Kafka, RabbitMQ), кто владеет какими данными. Диаграмма последовательности бизнес-сценария сразу показывает стыки и точки отказа.
Дальше уровни проверок, от дешёвых к дорогим:
- компонентные тесты: сервис поднимается отдельно, соседи подменяются заглушками WireMock, база и брокер поднимаются в Testcontainers;
- контрактные тесты: Pact или Spring Cloud Contract фиксируют ожидания потребителя от API и формата сообщений, ломающее изменение ловится в CI провайдера до стенда;
- интеграция стыков: реальные пары сервисов, сериализация, таймауты, ретраи, идемпотентность при повторной доставке;
- E2E: несколько ключевых сценариев вроде оформления и оплаты заказа, а не каждая ветка. Они медленные и хрупкие;
- отказы: что видит пользователь, если сервис оплаты отвечает 30 секунд или лежит. Проверяются компенсации и отсутствие зависших статусов.
Для асинхронных сценариев нужна проверка итоговой согласованности: ожидание с опросом и таймаутом через Awaitility, а не фиксированный sleep. Сквозной trace id через OpenTelemetry показывает, на каком сервисе запрос потерялся.
Отдельный пункт: совместимость версий. Сервисы выкатываются независимо, и новая версия провайдера обязана работать со старым потребителем. Добавьте критерии входа и выхода и договорённость о тестовых данных.
Где спотыкаются
Покрывают всё сквозными UI-тестами. Прогон идёт часами, падает от любого сбоя стенда, и по красному тесту непонятно, какой сервис виноват.
Проверяют только позитивный сценарий. Частичные отказы, дубли сообщений и нарушенный порядок событий остаются без проверки, а на проде ломается именно это.
Гоняют тесты на общем стенде с общими данными. Параллельные прогоны портят друг другу заказы, тесты падают случайно. Данные лучше создавать через API под каждый тест.