Как проверить, что запросы отправляются с нужными параметрами на нужный endpoint?

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

Умеете ли вы смотреть глубже интерфейса и видеть сам HTTP-запрос, а не только результат на экране. Следом почти всегда спрашивают, как автоматизировать такую проверку и как смотреть трафик мобильного приложения.

Как отвечать

Сначала назовите, что именно сверяете со спецификацией, обычно это OpenAPI или описание в задаче:

• метод и путь: POST на /api/v1/orders, а не PUT и не соседняя версия API;
• query-параметры: имена, значения, кодирование кириллицы и пробелов, отсутствие лишних и пустых;
• заголовки: Authorization, Content-Type, ключ идемпотентности, если он предусмотрен;
• тело: структура JSON, типы (строка "10" против числа 10), формат дат, поведение необязательных полей;
• количество и момент: ровно один запрос на действие, без дублей от двойного клика, с дебаунсом в строке поиска.

Инструменты по уровню:

• вручную в вебе: вкладка Network в DevTools, разделы Headers и Payload, пункт «Copy as cURL», чтобы воспроизвести запрос отдельно;
• прокси: Charles, Fiddler, mitmproxy, Proxyman. Для мобильного приложения нужен сертификат прокси на устройстве, а приложения, собранные под Android 7 и новее, по умолчанию не доверяют пользовательским сертификатам, поэтому в отладочную сборку добавляют network_security_config;
• автотесты UI: в Playwright page.waitForRequest() и request.postDataJSON(), в Cypress cy.intercept() с алиасом и cy.wait('@alias'), после чего проверяете request.body;
• на стороне сервера: логи или мок-сервер вроде WireMock, где можно проверить, что запрос с нужными параметрами пришёл заданное число раз.

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

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

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

Путаются в кэше и служебных запросах: принимают OPTIONS от CORS за основной вызов или не видят запрос, потому что ответ пришёл из кэша браузера или Service Worker.