Как тестировать API с 202 Accepted и не пропускать сбои фоновой обработки
Прилетел 202, автотест зелёный, все выдохнули. А через несколько дней выясняется: часть операций так и не дошла до успешного финала. Знакомо? Причина банальная — ты смотришь только на ответ HTTP-обработчика, а вся асинхронная цепочка при этом висит без контроля.
Ниже — как собрать нормальный тест для API с polling: старт операции, проверка статуса, валидация финального результата и аккуратный повторный запрос.
Тестирование API: 20 проверок, которые обязан уметь каждый QA
Чаще всего «тестирование API» — это кинуть запрос и порадоваться, что прилетело 200. На собесе такой подход живёт минуты две. А вот на проде вылезает то, чего код ответа в упор не видит: в ответе чужой заказ, вместо ошибки валидации — тихий 500, товар со склада так и не списался.
Дальше — 20 базовых проверок. Именно они отделяют того, кто реально тестит API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы. И всё это на одном сквозном сценарии, с примерами на curl и в Postman.
Новичок соберёт себе порядок действий, опытный — сверится и поймёт, куда расширять набор тестов.
Completion gate для локальных моделей: как отделить завершённый ответ от оценки качества
Три маршрута выполнили по десять сценариев из десяти, но выбирать модель по этой таблице рано. Completion gate отделяет целый артефакт, который вообще можно оценивать, от проверки качества и человеческой приёмки.
Можно ли поймать breaking change REST API до интеграционных тестов?
Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.