Что такое синхронные и асинхронные запросы

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

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

Как отвечать

Разведите два уровня, их часто смешивают:

• синхронный запрос: клиент отправил запрос и ждёт ответа, в котором уже лежит итог. Например, GET /users/42 вернул 200 и тело пользователя. Проверка простая: статус, схема, данные;
• асинхронность на уровне кода: клиент не блокируется, пока ждёт ответ. В браузере это fetch с Promise, в тестах async/await. Страница продолжает работать, данные подгружаются позже;
• асинхронность на уровне API: сервер принимает задачу и сразу отвечает 202 Accepted, а работа идёт в фоне. Результат приходит через опрос статуса (GET /jobs/{id}), вебхук, WebSocket или сообщение в очереди вроде Kafka или RabbitMQ.

Для тестировщика отсюда следуют разные техники. В асинхронном API проверяют сам факт приёма задачи, затем опрашивают статус с таймаутом и интервалом (в Java для этого есть библиотека Awaitility) и сверяют итоговое состояние в базе или в очереди. Отдельно смотрят негативные сценарии: задача упала, повторная отправка, дубли, порядок сообщений.

В UI автотестах работают явные ожидания: в Selenium WebDriverWait с условием, в Playwright встроенное автоожидание локаторов и expect с повторами. Вкладка Network в DevTools показывает, какие запросы уходят параллельно и что интерфейс делает, пока ответа нет: лоадер, заглушка, заблокированная кнопка.

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

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

Считают, что 200 или 202 на асинхронную операцию означает успех. На деле это только «задача принята», итог нужно проверить отдельно.

Путают асинхронность с многопоточностью. Асинхронный код в браузере выполняется в одном потоке через event loop, а не «параллельно».