Какие способы взаимодействия между сервисами используются: REST или другие интеграции?
Что проверяют
Для тестировщика здесь важно не перечисление протоколов, а понимание, чем и как вы проверяете каждый из них. Следом часто спрашивают, как вы тестировали асинхронное взаимодействие: сообщение ушло в очередь, а результат появился через несколько секунд.
Как отвечать
Назовите способ интеграции и сразу, как вы его проверяете:
- REST: Postman, curl, в автотестах REST Assured или
requestsс pytest. Проверяете код ответа, тело, заголовки, схему по OpenAPI и негативные сценарии: пустые и лишние поля, неверные типы, отсутствие авторизации (401 против 403); - SOAP: SoapUI или тот же Postman, запрос собирается по WSDL. Ошибка приходит как
Faultвнутри XML, и её содержимое тоже надо проверять; - gRPC: grpcurl, Postman, в коде клиент, сгенерированный из
.proto. Вместо HTTP-кодов свои статусы (NOT_FOUND,DEADLINE_EXCEEDED), отдельно проверяются стриминговые вызовы и дедлайны; - GraphQL: сервер часто отвечает 200 даже при ошибке, а сама ошибка лежит в массиве
errors. Проверяется выборка полей, глубина запроса и права на отдельные поля; - брокеры (Kafka, RabbitMQ): читаете топик или очередь через Kafka UI, консольный consumer или веб-интерфейс RabbitMQ. Проверяете формат сообщения, ключ, порядок, повторную доставку и то, что потребитель обрабатывает дубль идемпотентно.
Для изоляции от внешних систем используют заглушки (WireMock, MockServer), а согласованность контракта между командами проверяют контрактными тестами, например Pact.
Где спотыкаются
Ждут асинхронный результат через фиксированный sleep(5). Тест то падает, то тратит время зря. Правильнее опрашивать с таймаутом, как это делает Awaitility в Java или цикл с повторами в pytest.
Проверяют в GraphQL только код 200 и пропускают ошибку в теле ответа. Такой тест зелёный, даже когда запрос не вернул ни одного поля.
Тестируют только позитивный путь. Таймаут партнёра, повторная отправка того же сообщения и сообщение неверной схемы ломают интеграции чаще, чем основной сценарий.