Какие планы по автоматизации микросервисов с нуля
Что проверяют
Есть ли у вас стратегия, а не список инструментов: с чего начнёте, в каком порядке будете покрывать сервисы и как тесты встанут в CI. Следом обычно спрашивают, как вы проверите взаимодействие сервисов, которые релизятся независимо.
Как отвечать
Покажите план по этапам, опираясь на свой опыт и свои цифры. Если с нуля вы автоматизацию не строили, скажите прямо и опишите, как сделали бы, сославшись на то, что уже пробовали в меньшем масштабе.
- разведка: список сервисов и связей, спецификации OpenAPI, протоколы (REST, gRPC, Kafka), какие есть стенды и как на них попадают данные. Отдельно выясните, что уже покрыто юнит-тестами разработчиков;
- стек: язык и раннер под язык команды, чтобы разработчики могли читать и чинить тесты. Для Java это JUnit 5 и REST Assured, для Python pytest и
httpx, отчёты в Allure; - первые недели: смоук критичных бизнес-сценариев через API и запуск в CI на каждый merge request. Быстрая польза важнее полного покрытия;
- изоляция: компонентные тесты сервиса с зависимостями в Testcontainers (PostgreSQL, Kafka) и заглушками соседей через WireMock;
- контракты: consumer-driven контракты через Pact, чтобы несовместимое изменение API ловилось до деплоя, а не на общем стенде;
- сквозные сценарии: их немного, гоняются ночью или перед релизом, потому что медленные и хрупкие.
Назовите метрики успеха: время прогона, доля нестабильных тестов, дефекты, пойманные до стенда.
Где спотыкаются
Начинают с UI-тестов через Selenium поверх всех сервисов. Такой набор долго пишется, медленно гоняется и падает от проблемы любого сервиса, так что причину каждый раз ищут вручную.
Проверяют асинхронные сценарии через sleep. Для событий через брокер нужен опрос с таймаутом, например Awaitility в Java, иначе тесты либо медленные, либо нестабильные.
Опираются на общий стенд с грязными данными и одним набором пользователей. Без своих тестовых данных и их очистки половина падений окажется не про баги.