15 октября 2026 г.

Что нового

Теперь вы можете писать Postman Mock Servers на JavaScript. Они запоминают состояние между запросами. Они работают на вашем ноутбуке, в CI или в облаке.

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

Мы называем это программными моками (code-based mocks).

Устранение «узкого места»

Агенты создают то, что вы просите, за считанные минуты. Попросите API корзины покупок, и вы получите его мгновенно.

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

Теперь «узкое место» — это инструменты, которые мы даем людям и агентам. Поэтому мы создали инструмент, который работает со скоростью вашей мысли.

Вот повседневная версия этой проблемы. Две команды, один контракт. Ваш агент пишет сервис корзины за десять минут. Затем он застревает на три спринта из-за проверки схемы, необходимости подготовки базы данных и платежного провайдера, который еще не подключил вас. Тем временем команда приложения ждет URL-адрес, который вы не можете им дать.

Пока ничего не работает, команды, вызывающие ваш сервис, работают на основе документации со спецификациями и догадок. Код компилируется, тесты проходят, потому что тесты делают те же догадки, что и код. Всё ломается, когда ваш сервис выходит в продакшн.

Направление их на реальное окружение не сильно помогает. Каждое тестовое оформление заказа уменьшает реальные запасы и вызывает реального платежного провайдера. Возникают расходы и ограничения по частоте запросов (rate limits). И вы всё еще не можете вызвать конкретную ошибку по требованию.

Вашему агенту нужно безопасное место для практики. Что-то, что ведет себя как продакшн, не являясь им. Добавьте товар в корзину, и следующее чтение этой корзины должно показать этот товар. Попросите код 429 на третьем вызове и получайте его каждый раз, чтобы агент мог доказать, что его логика повторных попыток работает.

Сохраненный пример отвечает на один вопрос: что возвращает этот эндпоинт? Когда вы создаете интеграцию, вам нужен ответ на другой вопрос: как ведет себя этот сервис? Этот ответ — логика. Поэтому мы превратили моки в программы.

Мок — это программа

Из этого следуют три вывода.

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

Перед началом

Вам понадобится настольное приложение Postman или Postman CLI. Скачайте Postman или установите Postman CLI и подключите свой репозиторий в рабочем пространстве Postman.

Установите CLI на macOS или Linux и войдите в систему:

Или через npm:

затем:

Создание с помощью агентов

Я создавал тот сервис корзины, и вот что я попросил своего агента в этом репозитории:

Создай сервис корзины, который добавляет товар, получает содержимое корзины и оформляет заказ для подтверждения. Он должен сохранять состояние, поэтому добавление товара должно менять то, что возвращает корзина. Затем сделай так, чтобы он выдавал ошибку так же, как реальный сервис, и дай мне URL, который смогут использовать команда приложения и наш CI.

Создай сервис корзины, который добавляет товар, получает содержимое корзины и оформляет заказ для подтверждения. Он должен сохранять состояние, поэтому добавление товара должно менять то, что возвращает корзина. Затем сделай так, чтобы он выдавал ошибку так же, как реальный сервис, и дай мне URL, который смогут использовать команда приложения и наш CI.

Вот что пришло в ответ. Агент выполнил каждую команду самостоятельно, пока я читал diff. Конечно, вы можете выполнить их через приложение Postman или CLI.

1. Он выбрал правильную команду

Это создает локальный мок: JavaScript-файл с HTTP-сервером Node.js.

Вы также можете начать с коллекции Postman или спецификации OpenAPI на вашем компьютере:

Он сделал это правильно с первой попытки, что стоит отметить. Моки в CLI имеют три команды: generate, run и deploy. Агент, который угадывает, тратит попытку впустую. Этот не угадывал, потому что Postman CLI поставляется с навыком создания моков, который подсказывает ему порядок действий. Агенты обычно терпят неудачу, потому что не знают о существовании функции, а не потому, что функция отсутствует.

В приложении. Нажмите + → Mock. Postman создает локальный сервер с примером корзины покупок.

2. Он написал сервис

Код сначала считывает корзину:

Добавление товара сохраняет корзину обратно с помощью pm.state.set, чтобы следующий GET увидел его. Агент добавил маршруты для добавления товара, чтения корзины и оформления заказа. Он пометил каждый из них:

Комментарий @endpoint перечисляет маршрут на боковой панели Postman и позволяет отправить запрос из кода при наведении курсора. Когда я открыл приложение позже, всё было легко просматривать.

Тот же трюк работает для купона, отсутствующего товара или истекшего токена.

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

3. Он проверил свою работу

Мок работает на localhost:4500 и выводит журнал запросов в реальном времени. Если этот порт занят, он выбирает другой. Во втором терминале агент вызвал то, что только что написал:

Второй GET содержит товар, который добавил POST. Затем оформление заказа:

Оформление заказа очищает корзину. Последующий GET /cart возвращает пустоту, а второй вызов оформления заказа возвращает 400.

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

В приложении. Нажмите Start, затем Send Request из журналов, из аннотаций в коде или с боковой панели. Наблюдайте за журналами и сохраненным состоянием по ходу дела.

4. Он заставил сервис вести себя неправильно

Я просил об ошибке, потому что ошибки — часть контракта. Сервис корзины должен возвращать 429 своим вызывающим сторонам, когда они перегружают товар с высоким спросом или сталкиваются с неожиданными ошибками 5xx. Агент включил Behaviors — настройки для ограничения частоты запросов и режима хаоса. Затем он повторил ту же последовательность против сервиса корзины, который теперь стал ненадежным.

Журнал показал то, что увидел бы вызывающий абонент. Периодические 5xx из режима хаоса, затем чистые 429, как только сработало ограничение частоты запросов.

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

5. Он предоставил стабильный URL

Deploy запускает мок как живой мок-сервер в облаке Postman и дает ему стабильный URL, который могут использовать ваша команда, CI и любой агент в репозитории:

Мок-сервер по умолчанию является приватным и требует заголовок x-api-key. Вы можете добавить --public, чтобы сделать его доступным для всех.

В приложении. Нажмите Deploy.

Если вы вошли в приложение Postman или используете CLI, вы можете получить доступ к приватному mock-серверу без API-ключа. В противном случае получите свой API-ключ Postman.

Агент по-прежнему выполняет его, поэтому он считывает развернутый трафик так же, как считывал локальный лог:

--json значит больше, чем кажется. Это разница между логом, в который нужно вглядываться, и логом, который ваш агент может прочитать и обработать.

6. Он разделил вызывающих абонентов

Состояние по умолчанию является общим, поэтому два вызывающих абонента делят одну корзину. Заголовок x-mock-session дает каждому вызывающему абоненту свою собственную:

В корзине Алисы есть товар. Корзина Боба пуста. Три разработчика и их три агента могут использовать один mock-сервер, не мешая друг другу.

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

Вы по-прежнему остаетесь рецензентом

Агент выполнил работу. Но последнее слово осталось за вами.

Все это пришло ко мне в виде diff: файл JavaScript, который я мог прочитать, изменить с помощью агентов и отправить в git с помощью рабочих процессов Postman git. Это настоящая причина, по которой mock должен быть программой. Сохраненному ответу вы либо доверяете, либо нет. Программа — это то, что вы можете проверить.

И когда настоящий сервис корзины был выпущен с другим контрактом, исправлением стал pull request для mock-сервера. Этот mock также можно использовать для проверки контрактов. Я расскажу об этом подробнее в ближайшее время. А пока ознакомьтесь с docs.

К чему это ведет

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

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

После этого обратная связь станет лучше. Когда запрос нарушает контракт, код 400 мало чем помогает. Помогает ответ, который может прочитать ваш агент: какое поле было неверным, что ожидалось и каков правильный порядок вызовов. Тогда он исправит себя за тот же цикл, а не в следующем спринте.

Далее мы рассмотрим сценарии: как заставить один mock вести себя по-разному в разных ситуациях, чтобы один и тот же POST /cart мог ограничивать частоту запросов для товара с высоким спросом и оставаться обычным в остальных случаях. Если вы хотите углубиться в тему прямо сейчас, посетите Центр обучения Postman.

Попробуйте

Создание и запуск mock-серверов на основе кода локально бесплатны для всех. Облачное развертывание доступно в платных тарифах. Скачайте Postman или установите Postman CLI:

Затем укажите на него своему агенту и опишите зависимость, которой у вас еще нет.