Что такое моки в Postman
Что проверяют
Умеете ли вы разблокировать тестирование, когда сервиса ещё нет или он нестабилен, и видите ли границу: мок проверяет ваш клиент и ваши сценарии, но ничего не говорит о поведении настоящего сервера.
Как отвечать
Мок-сервер в Postman это HTTP-адрес, который Postman поднимает у себя и отвечает сохранёнными примерами (examples) из вашей коллекции. Ключевое: моком становится не запрос, а пример ответа, сохранённый рядом с запросом. Входящий вызов сопоставляется с примером по методу и пути; если примеров несколько, нужный выбирается заголовком x-mock-response-code или x-mock-response-name. Приватному моку нужен заголовок x-api-key.
Порядок работы простой: сохранить примеры ответов (успешный, 404, 500), создать на коллекции мок-сервер, подставить его адрес в переменную окружения вместо боевого.
Зачем это тестировщику:
- клиентская часть готова раньше бэкенда, и проверки пишутся параллельно, а не после;
- воспроизводятся ответы, которые на стенде не получить: пустой список, 500, битое тело, медленный ответ;
- автотесты отвязываются от внешнего платного или капризного сервиса и перестают падать по чужой вине.
Хорошо добавить, что мок не заменяет проверку на реальном стенде, а сдвигает её: часть сценариев остаётся обязательной против настоящего API.
Где спотыкаются
Забывают, что мок живёт своей жизнью. Настоящий сервис поменял формат поля или код ошибки, примеры остались прежними, тесты зелёные, а на проде всё сломано. Лечится сверкой примеров со схемой или спецификацией и обязательным прогоном части проверок против живого сервиса.
Ждут от мока того, чего в нём нет. Мок-сервер не валидирует тело запроса и не хранит состояние: созданный ресурс не появится в следующем вызове списка, а неверный запрос получит тот же успешный ответ. Сценарии с состоянием на моке не проверяются в принципе.
Сохраняют в примеры реальные ответы со стенда вместе с персональными данными и токенами, а сам мок оставляют публичным. Получается общедоступный адрес, который отдаёт всё это любому желающему.