Как происходит интеграция и проверка в тестах: используется REST или другие методы

Что проверяют

Как ваши автотесты добираются до системы и чем подтверждают результат: только через интерфейс, через API или ещё и через базу и очереди. Следом обычно просят рассказать, как вы проверяете асинхронный процесс, где ответ API ещё ничего не гарантирует.

Как отвечать

Опишите каналы, через которые тест общается с системой, и объясните, почему основная масса проверок идёт не через UI:

• REST API: основной канал. На Java это REST Assured поверх JUnit 5, на Python requests или httpx с pytest, для ручной работы и прогона коллекций Postman и Newman. Проверяют код ответа, тело, заголовки и соответствие JSON Schema или OpenAPI-спецификации;
• gRPC и GraphQL: если сервисы общаются так, тесты ходят через сгенерированные клиенты или grpcurl. У GraphQL ошибка часто приходит с кодом 200 внутри поля errors, это проверяют отдельно;
• база данных: после вызова API тест читает таблицу и убеждается, что запись появилась с нужными полями. Так ловят побочные эффекты, которые API не возвращает;
• очереди и брокеры (Kafka, RabbitMQ): тест подписывается на топик и ждёт событие. Для ожидания используют Awaitility или повторы с таймаутом, а не sleep;
• заглушки внешних систем: WireMock или MockServer подменяют платёжный шлюз или сервис партнёра, чтобы тест не зависел от чужого стенда;
• UI: Playwright или Selenium только для ключевых пользовательских сценариев, остальное дешевле и стабильнее проверять уровнем ниже.

Хорошо звучит пример из вашего проекта: создали заказ через API, проверили статус в базе, дождались события в Kafka, убедились, что заглушка платёжки получила правильный запрос. Если на прошлом месте было только ручное тестирование в Postman, так и скажите и покажите, что понимаете, как это автоматизировать и встроить в CI.

Где спотыкаются

Проверяют только код ответа. Сервис вернул 200, а в теле пустой массив или ошибка валидации, и тест всё равно зелёный.

Ставят Thread.sleep(5000) для асинхронных проверок. Такие тесты то падают на медленном стенде, то тратят время впустую на быстром.

Строят всё на UI-тестах. Прогон растягивается на часы, а упавший тест не показывает, какой из сервисов виноват.