Postman: code-based mocks — мок-серверы теперь на JavaScript

Postman выпустил code-based mocks — мок-серверы теперь можно писать на JavaScript. Они запоминают состояние между запросами, запускаются локально, в CI или облаке и помогают тестировать интеграции без реальных сервисов.

19.10.2026

// Новости

~ 6 мин. 4

Коротко о главном:

Postman представил code-based mocks: мок-серверы теперь пишутся на JavaScript.
Моки сохраняют состояние между запросами через pm.state и запускаются локально, в CI или облаке.
Можно включать Behaviors для имитации ошибок: rate limit, chaos mode.
Локальное создание и запуск моков бесплатны, облачное развёртывание — на платных планах.

Postman представил code-based mocks — новый способ создания мок-серверов, при котором вы пишете не набор сохранённых ответов, а полноценную программу на JavaScript. Это главное обновление в Postman за последнее время: теперь что нового в Postman касается не только коллекций и примеров ответов, но и логики поведения сервисов.

Мок-серверы на коде запоминают данные между запросами, запускаются на вашем ноутбуке, в CI или в облаке Postman и управляются из терминала. Каждый шаг — команда, поэтому с моками может работать и ваш кодирующий агент: создать, запустить, намеренно сломать и выдать CI стабильный URL.

Зачем понадобились моки на коде: узкое место — не код, а окружение

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

Сохранённый пример отвечает только на вопрос «что возвращает эндпоинт». При построении интеграции нужен ответ на другой вопрос: «как ведёт себя сервис». Ответ на него — это логика. Поэтому в Postman моки стали программами.

Что умеют code-based mocks в Postman

Из идеи «мок — это программа» следуют три ключевые возможности:

Мок помнит. Через pm.state можно сохранять и читать данные между запросами: методы get, set, delete и push. Второй запрос знает, что сделал первый.
Мок можно написать агенту. Код — это то, что и вы, и агент можете читать, писать, сравнивать и ревьюить. Postman Agent Mode уже имеет доступ к вашим спецификациям, коллекциям и истории запусков.
Мок путешествует с вашей работой. Один и тот же файл запускается на ноутбуке, в CI и как развёрнутый мок-сервер, которым пользуется команда. Файл можно хранить в репозитории с нативным git в Postman.

Кроме того, мок может возвращать ваши сохранённые примеры, когда запрос совпадает: для этого есть pm.mock.matchRequest и pm.mock.sendExample. Примеры и логика живут в одном файле.

Как это работает на практике: пример с корзиной покупок

В блоге Postman описан сценарий: агент по запросу создаёт сервис корзины, который добавляет товар, возвращает корзину и оформляет заказ. Сервис должен сохранять состояние, чтобы добавленный товар появлялся в следующем GET-запросе, а также уметь падать так, как это будет делать реальный сервис.

Агент выполнил все команды сам, а автор читал дифф. Вот что произошло:

Агент выбрал правильную команду для создания локального мока — JavaScript-файла с HTTP-сервером на Node.js. В CLI mocking есть три команды: generate, run и deploy, и агент не угадывал, а следовал навыку, который поставляется с Postman CLI.
Агент написал сервис: добавление товара сохраняет корзину через pm.state.set, следующий GET её видит. Каждый маршрут помечен комментарием @endpoint, чтобы его было видно в боковой панели Postman.
Агент проверил свою работу: мок запустился на localhost:4500 с живым логом запросов. Второй GET показал товар, добавленный POST-запросом, оформление заказа очистило корзину, а повторный checkout вернул 400.
Агент заставил сервис сбоить: включил Behaviors — регулятор rate limit и chaos mode. В логе появились периодические 5xx от chaos mode, а затем чистые 429, когда сработал rate limit.
Агент развернул мок в облаке Postman и получил стабильный URL для команды и CI. По умолчанию мок-сервер приватный и требует заголовок x-api-key; флаг --public делает его доступным всем.
Агент разделил состояние между вызывающими: заголовок x-mock-session даёт каждому клиенту свою корзину, так что несколько разработчиков и их агентов могут пользоваться одним мок-сервером, не мешая друг другу.

Весь прогон занял примерно время одного стендапа. Реальный сервис корзины всё ещё в нескольких спринтах, но никто его не ждёт.

Вы остаётесь ревьюером

Агент сделал работу, но последнее слово не за ним. Всё приходит к вам в виде диффа: JavaScript-файл, который можно прочитать, изменить с помощью агентов и запушить в git через git-процессы Postman. Именно поэтому мок должен быть программой: сохранённому ответу вы либо доверяете, либо нет, а программу можно отревьюить.

Когда реальный сервис вышел с другим контрактом, исправление стало пул-реквестом к моку. Мок можно использовать и для проверки контрактов — подробнее об этом Postman обещает рассказать позже.

Кому будет полезно

Новость будет полезна командам, которые разрабатывают и тестируют интеграции, а также тем, кто внедряет агентов в процесс разработки.

Разработчикам и тестировщикам API — чтобы тестировать интеграции до появления реального сервиса и воспроизводить сбои по запросу.
CI/CD-инженерам — чтобы получить стабильный URL мока для пайплайнов и не зависеть от staging-окружений.
Тимлидам и архитекторам — чтобы ревьюить поведение мока как код и синхронизировать контракты между командами.
Командам, использующим ИИ-агентов — чтобы агент мог самостоятельно создать, проверить и развернуть мок, а вы — проверить дифф.

Для работы понадобится приложение Postman для десктопа или Postman CLI. Локальное создание и запуск code-based mocks бесплатны для всех, облачное развёртывание доступно на платных планах. Чтобы выбрать подходящий план, посмотрите Postman Solo на 1 год для индивидуальной работы, Postman Team на 1 год для совместной работы команды или Postman Enterprise на 1 год для крупных организаций.

Что дальше: симуляции и сценарии

Один мок — это одна зависимость. В реальных системах зависимостей несколько, и интересные сбои происходят между ними: платёжный сервис отвечает успешно, а инвентарь отваливается по таймауту.

Следующий шаг — Simulation: несколько моков, сгруппированных за одним адресом на домене команды, каждый со своим состоянием и Behaviors. Их можно будет строить из спецификаций, захваченного трафика или тестовых прогонов и поддерживать в актуальном состоянии.

Затем Postman обещает улучшить обратную связь: вместо невнятного 400 агент получит читаемый ответ с указанием, какое поле неверно, что ожидалось и каков правильный порядок вызовов. Это позволит агенту исправляться в том же ходе, а не в следующем спринте. Также в планах — сценарии, когда один мок ведёт себя по-разному в разных ситуациях.

Вопросы и ответы

Что такое code-based mocks в Postman?

Это мок-серверы, которые пишутся на JavaScript и ведут себя как программа: сохраняют состояние между запросами через pm.state, могут имитировать сбои и запускаются локально, в CI или в облаке Postman.

Сколько стоит использование code-based mocks?

Создание и запуск моков локально бесплатны для всех. Облачное развёртывание мок-сервера доступно на платных планах Postman. Уточнить подходящий план можно у менеджеров ЛегаСофт.

Нужен ли Postman CLI для работы с моками на коде?

Можно работать через приложение Postman для десктопа или через Postman CLI. CLI удобен для автоматизации и для агентов: он содержит навык mocking с порядком команд generate, run и deploy.

Купить лицензии Postman для компании можно в «ЛегаСофт»: подберём подходящую редакцию и срок подписки, оформим закрывающие документы для юридического лица и проконсультируем по внедрению. Оставьте заявку на сайте или свяжитесь с нашими менеджерами.