На этой странице
Зелёный тест может скрывать отсутствующее правило. В условном примере агент подключает магазин к платформе email. Тестовый сервер принимает обновление контакта и возвращает аккуратный 200. Агент завершает задачу, тест проходит.
В реальной системе назначения действует дополнительное правило: пользовательский атрибут нужно объявить до записи его значения в контакт. Тестовый сервер правило не имитировал. Его зелёный результат кое-что доказывает об агенте в тестовом мире и ничего о недостающем правиле настоящего мира.
Это основной обмен при имитации. Опасные или дорогие действия становятся повторяемыми. Но возникает вторая система, поведение которой может расходиться с первой.
Замена позволяет проверять действия
Чтобы проверить действующего агента, дайте ему цель, среду и наблюдаемое конечное состояние. Обсуждение имитированных сред для агентов описывает эту структуру для браузерных и офисных задач. Среда позволяет проверяющему сравнить оставленное агентом состояние с известным правильным результатом.
Для интеграции замена может предоставить небольшой набор операций: перечислить поля, создать контакт, обновить его и прочитать обратно. Тестовый набор может содержать объявленное поле FNAME и отсутствующее CUSTOM_TIER. Тест попросит агента предложить сопоставление и отклонит запись CUSTOM_TIER до появления его определения.
Замена полезна, поскольку каждый запуск начинается из одинакового состояния. Можно менять одно условие за раз: отсутствующее поле, отказ в доступе, старую версию схемы или неоднозначный идентификатор. Последовательности вызовов и результаты агента можно сравнивать между моделями или промптами.
Это сильнее текстового вопроса о том, что агент сделал бы. Проверяется, что он действительно вызвал в контролируемом мире.
Тестовый набор должен иметь состояние до и после каждого вызова, а не только заранее подготовленный ответ. Если агент создаёт контакт дважды, второй вызов должен показать поведение с дубликатом, которое требуется проверить. Если агент читает поле после записи, чтение должно возвращать сохранённое состояние. Иначе правдоподобный запрос пройдёт тест без подтверждения, что последовательность дала нужную запись.
Точность имитации является частью теста
Разумное возражение: «У поставщика есть тестовая среда, зачем ещё одна?» Пользуйтесь тестовой средой поставщика, если она поддерживает нужный случай и безопасна для данных. Местная замена оправдана, если требуются одинаковый сброс, намеренные сбои или вызовы, которые нельзя устроить в среде поставщика. За неё тоже платят поддержкой. Каждое смоделированное правило может ошибаться или устареть.
Официальное API контактов Brevo указывает, что атрибуты должны существовать в аккаунте, а значения не того объявленного типа игнорируются. Замена, отклоняющая любое неверное значение, будет вести себя иначе. Она научит агента ожидать ошибку, которой не будет.
Запишите, какое поведение поставщика покрывает замена. Поддерживайте небольшой набор проверок контракта в настоящем API или его поддерживаемой тестовой среде. Если проверка находит разницу, исправьте замену и добавьте обнаруживший её случай. Имитация является моделью поставщика, не его заменой.
То же относится ко времени. Замена с мгновенным появлением каждой записи упустит процесс, который читает слишком рано. Замена с задержкой каждой записи создаст сбои, отсутствующие у поставщика. Имитируйте время лишь там, где оно влияет на проверяемое решение, а остальное отмечайте как неохваченное. Успешный тест тогда означает точно следующее: агент совершил эти действия при данных смоделированных правилах.
Руководство Tajo по коннектору Brevo показывает ту же практическую проблему со стороны магазина: успешный запрос может оставить поле пустым. Тест полезен, только если проверяет поле, а не один ответ HTTP.
Имитация проверяет агента при смоделированных правилах. Проверки контракта сравнивают их с настоящим назначением перед ограниченным просмотром.
От безопасной репетиции к ограниченным данным
После успешной имитации проведите небольшой просмотр в реальной системе. Выберите несколько записей с явным ожидаемым состоянием назначения: обычную, с отсутствующим необязательным полем и запись, согласие которой запрещает маркетинговое использование. Проверяйте сохранённое назначением состояние. Не выводите результат только из отправленного запроса.
Синтетический предпросмотр и проверка целевой системы отвечают на разные вопросы. Предпросмотр сопоставления Tajo тестирует преобразование без записи в цель. Предлагаемый вид активности ниже показывает следующую границу: даже применённое изменение требует проверки состояния в целевой системе. Последний шаг остаётся в ожидании, чтобы репетицию не приняли за доказательство.
Завершённая запись всё ещё требует доказательств
Завершилась ли синхронизация клиентов?
Запись применена. Проверка ожидается.
Состояние в целевой системе ещё не проверено.
Активность синхронизации
- Запрос принят
- Изменение применено
- Проверка целевой системы ожидается
Пример выполнения · 14:32 UTC
Что известно
- Ответ провайдера
- Принято
- Результат записи
- Применено
- Повторное чтение из целевой системы
- Ожидается
Успешный вызов не доказывает конечное состояние.
Предлагаемый вид основан на ленте активности Tajo. Иллюстрация добавляет состояние проверки; она не утверждает, что повторное чтение из целевой системы уже реализовано.
Ограничьте просмотр и явно определите остановку. Сбой должен запрещать широкое включение и указывать на точное расхождение: определение поля, идентификатор, тип, разрешение или время. Успех не доказывает одинаковое поведение всех будущих записей, но подтверждает контракт для выбранных случаев сегодня.
Последовательность разделяет два вопроса. Имитация спрашивает: «Следует ли агент правилу в управляемом мире?» Реальный просмотр спрашивает: «Подходит ли правило этому аккаунту поставщика?» Один вопрос не заменяет другой.
Руководство по Reverse ETL объясняет, почему окончательная работа повторяется на множестве записей. Повторение увеличит каждое оставшееся расхождение между имитированным и настоящим контрактом.
Репетируйте в мире, который можно сбросить. Затем изучайте мир, который сбросить нельзя.
Часто Задаваемые Вопросы
Что проверяет имитация назначения?
Она проверяет ожидаемые вызовы агента, соблюдение разрешений, обработку известных ошибок и конечное состояние внутри имитации.
Чего она не доказывает?
Она не устанавливает полноту своей модели поставщика. Недокументированное поведение, время обработки и настройки отдельного аккаунта могут отличаться.
Что делать после успешной имитации?
Провести ограниченный предварительный просмотр или пробный запуск в настоящем назначении и проверить его состояние до широкого включения.