Какие HTTP методы можно использовать для тестирования POST-запроса

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

Понимаете ли вы, что POST тестируется не в одиночку, а вместе с жизненным циклом ресурса и негативными сценариями. Следом обычно спрашивают, чем POST отличается от PUT и что будет, если отправить один и тот же POST дважды.

Как отвечать

Разложите методы по ролям в тесте:

• POST: сам объект проверки. Корректное тело даёт 201 Created и заголовок Location, невалидное 400 или 422, неверный Content-Type даёт 415, без токена 401, без прав 403, дубль по уникальному полю 409;
• GET: проверка результата. Запросите созданный ресурс и сравните поля с отправленными, включая те, что сервер ставит сам: id, дату создания, статус по умолчанию;
• PUT и PATCH: следующий шаг сценария. Ресурс должен редактироваться, а поля, которые клиенту менять нельзя, игнорироваться или отклоняться;
• DELETE: удаление и заодно очистка тестовых данных, после него GET возвращает 404;
• OPTIONS и HEAD: OPTIONS покажет заголовок Allow и нужен при проверке CORS, браузер шлёт его как preflight перед POST с JSON с другого домена. HEAD проверяет заголовки без тела.

Отдельный негативный блок: отправьте на эндпоинт создания GET, PUT, DELETE. Корректный сервер отвечает 405 Method Not Allowed, а не 500 и не 200.

Назовите идемпотентность: POST не идемпотентен, два одинаковых запроса создадут две записи. Если API принимает заголовок вроде Idempotency-Key, проверьте, что повтор с тем же ключом возвращает первый результат. Инструменты: Postman или curl для ручной проверки, REST Assured или pytest с requests для автотестов.

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

Перечисляют методы из учебника и не объясняют, зачем каждый нужен именно в проверке POST. Интервьюер ждёт сценарий, а не определения.

Проверяют только код ответа. 201 при потерянном поле это баг, который найдёт только GET или запрос в базу.

Забывают про повтор запроса и про очистку: тестовые записи копятся на стенде и ломают соседние проверки на уникальность.