Есть ли у микросервиса многомодульная сборка
Что проверяют
Знаете ли вы, как устроен сервис, который тестируете: из каких модулей он собирается, где лежат автотесты и как их запускают. Заодно проверяют, не путаете ли вы модуль сборки с микросервисом. Следом обычно спрашивают, как прогнать тесты одного модуля и откуда автотесты берут модели запросов и ответов.
Как отвечать
Сначала разведите понятия. Микросервис это отдельный процесс со своим деплоем, который общается с другими по сети. Многомодульная сборка это разбиение кода одного проекта на части с общей родительской конфигурацией: в Maven это родительский pom.xml с <packaging>pom</packaging> и списком <modules>, в Gradle это include(...) в settings.gradle.kts. Модули собираются вместе и выходят одним релизом, независимого деплоя у них нет.
Типичное разбиение Java-сервиса:
api: DTO и контракт, часто OpenAPI-спецификация;client: сгенерированный клиент для других сервисов и автотестов;core: бизнес-логика;app: точка входа и конфигурация Spring Boot, из него собирается образ;integration-tests: API-тесты со своими зависимостями и профилем.
Для QA тут главная польза: автотесты подключают модуль client или api как зависимость, и изменение контракта ломает компиляцию тестов сразу, а не падением на стенде. Запуск одного модуля: mvn -pl integration-tests -am verify, где -am заодно собирает модули, от которых он зависит, или ./gradlew :integration-tests:test.
Ответ стройте на своём проекте: какие были модули и где жили тесты. Если сервис был одномодульным, это нормально для небольшого сервиса, просто объясните, почему дробить не требовалось.
Где спотыкаются
Путают модули с микросервисами и рассказывают про независимый деплой каждого модуля. Это другой уровень архитектуры.
Отвечают «сборкой занимались разработчики». Тестировщик, который не может сам запустить тесты нужного модуля, зависит от команды в каждой мелочи.
Копируют DTO из кода сервиса в отдельный проект автотестов. Контракт меняется, копия остаётся прежней, и тесты проверяют уже несуществующий API.