Проверить черновик без запуска бота

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

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

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

В редакторе также есть запуск сохранённой реакции для выбранного получателя. Он может отправить настоящее сообщение и выполнить рабочие действия. Для проверки несохранённых изменений на учебных данных используйте именно проверку черновика.

С правами чтения можно проверять черновик и открывать сохранённые примеры. Для сохранения нового примера нужны права записи. Временное изменение учебных данных не меняет саму реакцию.

Урок 1. Проверить ещё не сохранённую цепочку

1. Откройте новую реакцию или измените существующую. Сохранять её для теста не нужно.
2. Нажмите Проверка черновика. В Тип события выберите Текст и укажите /confirm в Текст события. Для события типа Команда заполните Команда без слеша, например confirm.
3. Выберите Канал для этой проверки и заполните Контекст, если сценарию нужны начальные значения. Можно оставить каналы из настроек реакции.
4. Добавьте учебные ответы для шагов чтения коллекций, HTTP или AI, если они есть в цепочке. Как это сделать, разобрано ниже.
5. Нажмите Проверить на этих данных. Откройте Входы и выходы шагов, Выбранный путь и Предполагаемые сообщения и записи.
6. Измените условие или данные черновика и запустите его снова. Выбранный путь должен соответствовать новой правке.

Предыдущего живого запуска и его идентификатора в журнале (trace ID) не требуется. Проверяется текущее содержимое формы, включая несохранённые изменения.

Если открыт вложенный редактор действия или кнопок, сначала примените его изменения либо закройте его. При незавершённом числе или JSON используйте Исправить значение. Проверка не подставляет вместо вашего текста последнее корректное значение. Заполнять название новой реакции и сохранять её только ради проверки не нужно.

Для простого первого опыта возьмите расчёт стоимости списка: в исходных данных две строки с ценой и количеством, после расчёта ожидаются суммы 3000 и 2000. Проверьте сами строки, а не только итоговый зелёный статус.

Откуда тест берёт данные

Есть три разных источника:

Учебный ответ часто называют fixture. Это заранее заданные данные вместо обращения к рабочему сервису. Например, вместо запроса в каталог вы задаёте найденные строки, а вместо изменения рабочей заявки используете её состояние в тестовой копии коллекции.

В поле Контекст ключи буквальные, а значения строковые. Массив или объект запишите как JSON внутри строки. Для первого урока из обработки списков можно вставить:

{
  "orders": "[{\"id\":\"o1\",\"customer\":{\"name\":\"Анна\"},\"price\":1500,\"quantity\":2},{\"id\":\"o2\",\"price\":2000,\"quantity\":1}]"
}

Если сценарий использует {{user_id}}, {{chat_id}} или имя пользователя, раскройте Дополнительно: seed и время и заполните Данные пользователя и диалога (JSON). Например:

{
  "actor": {"ChannelUserID": "guest-1", "FirstName": "Анна"},
  "conversation": {"ChannelChatID": "chat-1"}
}

Эти ID строковые и описывают учебного пользователя и диалог. Подстановка {{user_id}} возьмёт guest-1 из события; значение ctx.user_id в начальном контексте не заменяет его. Имена полей JSON чувствительны к регистру. Тип события, текст и команду задавайте основными полями выше.

Для ответа внешнего шага раскройте Ответы HTTP, чтения и ИИ, выберите Шаг – источник ответа, задайте статус и тело ответа, затем нажмите Применить ответ. Для технической ошибки используйте Смоделировать ошибку провайдера. Выбирайте нужный шаг в нужной реакции или версии блока: одинаковый ID внутри другого блока не делает его тем же источником. Для чтения страницы или запроса нужен результат в формате этого действия, а не произвольный ответ другого API.

Поле Все учебные данные (JSON) подходит для расширенных случаев. Оно сохраняет числа без округления. Если вы изменили отдельные поля учебного ответа или коллекции, сначала примените либо явно отмените эти изменения. Запуск не использует вместо них старый сохранённый ответ.

Для условного изменения записи и транзакции задайте схему коллекции, её записи и правила хранения. У каждой записи должны быть ID и время создания: от них зависит, считается ли запись доступной. Подтвердите, что учебные данные описывают всю коллекцию и все её правила. Пустой список означает «записей нет», а незаданный или неполный список означает «состояние неизвестно». Во втором случае проверка будет неполной: по нескольким строкам нельзя надёжно решить, что нужная запись отсутствует.

Например, для подтверждения заявки раскройте Виртуальные коллекции. Укажите имя bookings, затем вставьте в Полные метаданные коллекции:

{
  "name": "bookings",
  "schema": [
    {"name": "state", "type": "text"},
    {"name": "guest_id", "type": "text"}
  ],
  "retention": {"max_age_days": 0, "max_records": 0}
}

В Все записи укажите:

[
  {
    "id": 101,
    "data": {"state": "new", "guest_id": "guest-1"},
    "created_at": "2026-10-25T12:00:00Z"
  }
]

Это целая учебная коллекция из одной записи, без ключей дедупликации и ограничения хранения. Отметьте полноту данных и нажмите Применить полную коллекцию. В Дополнительно: seed и время задайте время после создания записи, например 2026-10-25T13:00:00Z. В проверяемом действии используйте ID 101 и того же владельца guest-1. Для своего сценария замените схему, записи и правила хранения на соответствующий учебный случай. ID записи задаётся положительным целым числом, не строкой; created_at содержит дату, время и часовой пояс.

Если транзакция включает сообщение-подтверждение, отдельно задайте учебные возможности канала: куда предполагается отправка, допустимый формат и размер текста. Это предположение для проверки логики. Оно не подтверждает права бота в рабочем канале или доставку сообщения.

Следующие действия получают результаты предыдущих шагов: расчёт работает с переданными строками, ветка проверяет рассчитанное значение, а сообщение показывает подставленный текст. Тест не просто рисует ранее записанный путь.

Если шагу нужен учебный ответ, которого нет, результат проверки будет неполным. Указанный шаг не следует считать успешно выполненным. Добавьте недостающие данные и повторите тест.

Урок 2. Проверить подтверждение и повторное нажатие

Используйте сценарий из исходов действий: условное изменение переводит заявку из new в confirmed и выбирает один из ответов.

Подготовьте три примера:

Если в цепочке есть HTTP-шаг, отдельно задайте для него учебную техническую ошибку и проверьте настроенный исход error. Конфликт записи проверяется по состоянию учебной коллекции, а ошибка HTTP задаётся в ответе этого HTTP-шага.

ID в начальном контексте и ID тестовой записи должны совпадать. Если условие сравнивает guest_id с {{user_id}}, задайте того же учебного пользователя в Данные пользователя и диалога (JSON) и в записи. Иначе тест проверит конфликт владельца вместо нужного случая.

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

У транзакции дополнительно проверьте откат: после конфликта в поздней операции тестовая копия коллекций не должна содержать ранних изменений. Упражнение с последним местом.

Каждый новый запуск начинает с заданного учебного состояния. Изменения предыдущей проверки сами в него не переносятся. Для проверки повторной транзакции нужна явно переданная история её результата в учебных данных. Повтор того же вызова должен вернуть прежний результат без второй записи и подтверждения. Две итерации цикла или два отдельных вызова блока считаются разными вызовами.

Как читать результат

• Данные шага показывают, что действие получило и что вернуло. Для списка проверяйте также полноту результата.
• Выбранная ветка объясняет, куда пошло выполнение. Сравните её с вашим ожидаемым случаем.
• Предполагаемые действия показывают отрендеренные сообщения и виртуальные изменения. Это план теста, а не подтверждение реальной отправки или записи.
• Пауза означает ожидание ответа по сценарию. Тест не создаёт рабочий диалог.
• Ошибка означает, что шаг не выполнился корректно.
• Неполная проверка означает недостающие учебные данные, неподдерживаемое действие или другую явно указанную границу. Такой результат не подтверждает работоспособность всей цепочки.

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

Если проверка остановилась по лимиту

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

В режиме проверки пока не поддерживаются условия отбора внутри JSONPath и пользовательские процедуры JSONPath. Используйте действия обработки списков для отбора данных. Ограничение может сработать и у выражения с небольшим итоговым ответом: перед вычислением учитывается возможный размер промежуточного результата.

Исходный JSON и отчёт сохраняют числа без дополнительного округления. При этом формулы используют те же правила, что и рабочий сценарий. В JP и выражениях с числами с плавающей точкой точность может потеряться во время самого вычисления. Для точного умножения и суммирования используйте операции обработки списков и итоги по коллекции.

Урок 3. Сохранить примеры для следующей правки

1. В Сохранённые примеры заполните Название нового примера, например booking-new, и нажмите Сохранить новый пример. Предыдущая запись в журнале выполнения не нужна.
2. Для других случаев сохраните booking-conflict и booking-missing с соответствующими данными. В пример входят определения сценария, событие, контекст, учебные ответы, seed и время.
3. Выберите нужный пример и нажмите Открыть выбранный пример. Повторить сохранённую версию проверяет его сохранённые определения.
4. После правки сценария нажмите Повторить с текущим черновиком. В этом сравнении меняются только определения: событие, контекст, учебные ответы, seed и время остаются взятыми из примера. Сравните выбранные ветки, значения и предполагаемые сообщения.

Чтобы изменить входные данные открытого примера, выберите Копировать в новую проверку. После правки выполните отдельную проверку и сохраните её под новым именем. Редактирование учебного ответа не должно незаметно менять смысл повтора сохранённого примера.

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

Сохранённый пример неизменяемый. Если имя занято другим случаем, введите новое: введённые данные сохранятся после ошибки. Если такие же данные уже сохранены под другим именем, сервер может вернуть исходный пример. Редактор покажет его настоящее имя и выберет его, а не создаст второй экземпляр. Примеры относятся к своему проекту.

Срок указан в Хранится до. Сейчас обычный срок составляет 90 дней, но ориентируйтесь на дату конкретного примера. После её истечения обновите список; недоступный пример не получится повторить как бессрочную резервную копию.

Фиксированное время и начальное значение случайного выбора (seed) в расширенных настройках позволяют повторять тесты с датами и случайным выбором. Один и тот же сценарий с теми же входными данными и настройками должен давать тот же результат. Для независимого случая используйте другой seed или время.

Не переносите рабочие секреты в учебные ответы. Сохраняемые примеры и отчёты проходят маскирование. После скрытия значения повторная проверка может стать неполной; это не подтверждение успешного выполнения. Для воспроизводимого случая используйте обычные учебные значения.

Что ещё проверить перед включением

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

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

Связанные материалы: действия, поля и списки, блоки, история изменений.