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