Сколько проектов по микросервисам
Что проверяют
Умеете ли вы тестировать систему, у которой нет одной точки входа. Число проектов нужно интервьюеру как повод спросить главное: чем ваша работа отличалась от тестирования монолита и как вы искали виноватого, когда сценарий падал.
Как отвечать
Назовите число и сразу разверните один проект: сколько сервисов, кто с кем общается синхронно, где очередь, какая часть была вашей. Дальше про сами проверки:
- уровень API отдельного сервиса, с заглушками на соседей;
- взаимодействие: контрактные проверки, чтобы правка схемы у поставщика ломала сборку, а не прод;
- сквозные сценарии, которых должно быть мало и только на критичный путь;
- асинхронная часть: как ловили сообщение в очереди, как проверяли повторную доставку и идемпотентность обработчика.
Отдельно расскажите про окружение и данные: поднимался ли набор сервисов локально, был ли общий стенд и как на нём уживались команды, как готовились данные, разложенные по нескольким базам, как вы находили место падения по сквозному идентификатору запроса в логах и трассировке.
Если проектов было мало, скажите честно и подробно разберите то, что реально делали.
Где спотыкаются
Называют микросервисами модули монолита или пару сервисов, ходящих в одну общую базу. Про базу спросят обязательно: общее хранилище означает, что сервисы нельзя выкатывать независимо, а это и есть главный признак.
Второе: сводят всё тестирование к сценариям через интерфейс. В распределённой системе такой тест падает по чужой причине, не показывает виновника и через месяц начинает мигать, после чего его перестают читать.
Третье: не могут объяснить, как изолировали сервис. Ответ «ждали, пока поднимут полный стенд» честный, но говорит, что заглушек и контрактных проверок в работе не было, а значит и опыт с микросервисами скорее пассивный.