Почему важно тестировать API через Postman или аналогичные инструменты?
Что проверяют
Умеете ли вы отделить проблему клиента от проблемы сервера и работать с контрактом API, а не с тем, что удалось разглядеть в интерфейсе. Заодно смотрят, понимаете ли, чем запрос из внешнего клиента отличается от запроса из браузера.
Как отвечать
Прямой запрос мимо приложения отвечает на главный вопрос отладки: кто сломал. Если тот же запрос вне браузера возвращает корректные данные, дело в клиентском коде. Если возвращает ошибку или другую форму ответа, чинить надо не фронтенд, и разговор с бэкендом начинается с готового доказательства.
Что это даёт на практике:
- виден настоящий контракт: коды ответов, формат ошибки, пагинация, заголовки кэширования;
- легко воспроизводятся состояния, которые в интерфейсе не вызвать: пустой список, просроченный токен, пустое значение в поле, ошибка сервера;
- коллекция с окружениями и переменной для токена избавляет от ручной пересборки запросов;
- сохранённые ответы становятся основой моков в тестах, чтобы не ходить в живой сервис.
Инструмент вторичен: curl, HTTPie, встроенный HTTP-клиент редактора. Файлы с запросами прямо в репозитории даже удобнее: они видны в ревью и не протухают в личной коллекции одного человека.
Где спотыкаются
Останавливают расследование на фразе «в клиенте API работает, в браузере нет». Внешний клиент не делает предварительный запрос и не применяет политику источника, поэтому именно отказы по CORS он не воспроизводит по определению.
Забывают про то, что добавляет сам браузер: куки с их ограничениями по источнику, режим отправки учётных данных, заголовки источника и реферера. Запрос, собранный руками, отличается от боевого, и вывод из сравнения получается неверным.
Считают ручную коллекцию заменой тестам. Она не запускается в конвейере и живёт на одной машине, поэтому расходится с реальностью через месяц. Проверки контракта нужны в коде проекта, а прогон коллекции при желании добавляют отдельным шагом сборки.