Расскажите про опыт работы с микросервисной архитектурой
Что проверяют
Понимаете ли вы, что меняется в тестировании при переходе от монолита, и умеете ли проверять асинхронные сценарии.
Как отвечать
Опишите систему и то, как её проверяете.
> «Восемь сервисов, общаются по REST и через Kafka, у каждого своя база. Тестирую два из них плюс сквозные сценарии. > > На уровне сервиса: API-тесты в Postman с проверкой схемы, зависимости заменены заглушками через WireMock. Отдельно проверяю поведение при недоступности соседа: таймаут, повтор, предохранитель. > > Асинхронные сценарии проверяю через сам брокер: смотрю тему в Kafka UI, убеждаюсь, что событие ушло с нужным ключом, и что обработчик идемпотентен, повторная доставка не создаёт вторую запись. Отдельно смотрю очередь недоставленных сообщений. > > Сквозных сценариев мало и только на критичный путь: они дорогие и нестабильные. Для контрактов между сервисами используем контрактные тесты, чтобы изменение ответа ловилось до релиза».
Полезно назвать инструменты разбора: сквозной идентификатор запроса в логах, трассировка в Jaeger, метрики в Grafana. Без них в распределённой системе непонятно, где именно сломалось.
Где спотыкаются
Тестируют микросервисы как монолит, только через интерфейс.
Не проверяют повторную доставку сообщений и идемпотентность.
Не знают про контрактные тесты и ловят поломки уже на стенде.
Не умеют читать трассировку и не могут локализовать, какой сервис виноват.