Стратегия тестирования API в микросервисах
Вопрос
Как ты построишь стратегию тестирования API продукта из десятка микросервисов?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Слои: юнит и интеграционные у разработчиков, API-тесты сервиса, контрактные между сервисами, немного e2e
Каждый сервис тестируется изолированно со стабами зависимостей
Контракты ловят ломающие изменения между командами
Сквозные e2e только на критичные бизнес-сценарии
Плюс нефункциональное: нагрузка, безопасность, отказоустойчивость; запуск в CI на каждый PR
Что могут спросить следом
- Как поступишь с внешним платёжным сервисом в тестах?
- Что делать с нестабильными тестами?
- Как измеришь покрытие API тестами?
Разбор
Я бы строил пирамиду под микросервисы. Внизу юнит-тесты и интеграционные тесты сервиса с настоящей базой в контейнере, их пишут разработчики, я помогаю с кейсами. Уровнем выше API-тесты каждого сервиса в изоляции: зависимости заменены стабами вроде WireMock, поэтому можно проверить и ошибки соседей, и таймауты. Между сервисами контрактные тесты, например Pact: они ловят ситуацию, когда одна команда переименовала поле, а другая об этом не знает. Сквозных e2e немного, только на деньги и ключевые пути: регистрация, заказ, оплата, потому что они дорогие и нестабильные. Внешние системы вроде платёжки всегда за стабами, плюс отдельный редкий прогон на их песочнице. Всё запускается в CI на каждый PR, флакающие тесты сразу в карантин с задачей на починку. Покрытие считаю по спецификации: сколько эндпоинтов и кодов ответа имеют хотя бы один тест. Отдельно планирую нагрузку, безопасность и проверку отказов: что будет, если сервис соседа упадёт.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.