Контракты между сервисами
Вопрос
У вас 20 микросервисов, интеграционный стенд постоянно сломан, а релизы ломают соседей. Как построите тестирование взаимодействий?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Проблема: общий стенд медленный и нестабильный, поломки видны поздно
Контрактные тесты consumer-driven (Pact) или проверка по OpenAPI
Контракт в CI потребителя и поставщика, брокер и can-i-deploy
Компонентные тесты сервиса с моками соседей (WireMock, testcontainers)
Небольшой набор E2E на ключевые сквозные сценарии
Версионирование API и правила обратной совместимости
Что могут спросить следом
- Чем Pact лучше проверки по OpenAPI?
- Кто владеет контрактами?
Разбор
Образцовый ответ: «Перестал бы опираться на общий стенд как на главный источник уверенности. Каждый сервис тестируется компонентно: настоящая база в testcontainers, соседи замоканы через WireMock. Взаимодействия закрываю контрактами: потребители в своих тестах генерируют Pact-контракты, брокер их хранит, поставщик проверяет в своём CI, а перед деплоем can-i-deploy говорит, совместима ли версия. Для публичных API достаточно проверки по OpenAPI-схеме. На стенде оставляю 10-20 E2E на сквозные сценарии вроде оплаты. Плюс правило: только обратно совместимые изменения, ломающие через новую версию»).
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.