Kaj lahko dokaže simuliran ciljni sistem

Zelen preizkus lahko skrije manjkajoče pravilo. V tem ponazoritvenem primeru mora agent povezati trgovino s platformo za e-pošto. Preizkusni strežnik sprejme posodobitev stika in vrne urejen odgovor 200. Agent opravi nalogo in preizkus uspe.

Resnični ciljni sistem ima dodatno pravilo: atribut po meri mora biti deklariran, preden ga posodobitev stika lahko nastavi. Preizkusni strežnik pravila ni modeliral. Njegov zelen rezultat dokazuje nekaj o agentu v preizkusnem svetu. O manjkajočem pravilu v živem sistemu ne dokazuje ničesar.

To je osnovna cena simulacije. Nevarna ali draga dejanja naredi ponovljiva. Hkrati ustvari drug sistem, katerega vedenje se lahko oddalji od prvega.

Zamenjava omogoča preizkuse dejanj

Če želite preizkusiti agenta, ki ukrepa, mu dajte cilj, okolje in opazno končno stanje. Razprava o simuliranih okoljih za agente to strukturo opisuje pri nalogah v brskalniku in znanjskem delu. Okolje preverjevalniku omogoča primerjavo stanja, ki ga je agent pustil, z znanim pravilnim rezultatom.

Pri integraciji bi zamenjava lahko izpostavila majhen nabor operacij ciljnega sistema: seznam polj, ustvarjanje stika, posodobitev stika in ponovno branje. Lahko bi hranila preizkusne podatke z deklariranim poljem FNAME in odsotnim poljem CUSTOM_TIER. Preizkus bi od agenta zahteval, naj predlaga preslikavo, nato pa zavrnil zapis, ki uporabi CUSTOM_TIER, preden obstaja njegova definicija.

Zamenjava je uporabna, ker se vsaka izvedba začne v istem stanju. Spreminjate lahko en pogoj naenkrat: manjkajoče polje, zavrnjeno dovoljenje, zastarelo različico sheme, dvoumen identifikator. Med modeli ali pozivi lahko primerjate zaporedje agentovih klicev in končno stanje.

To je močnejše od besedilnega vprašanja o tem, kaj bi agent naredil. Preverite, kaj je v nadzorovanem svetu dejansko poklical.

Preizkusnim podatkom dajte stanje pred vsakim klicem in po njem, ne le pripravljenega odgovora. Če agent dvakrat ustvari stik, naj drugi klic pokaže obravnavo podvojenega zapisa, ki jo želite preizkusiti. Če po zapisu prebere polje, naj branje vrne shranjeno stanje. Sicer lahko agent uspe s prepričljivo zahtevo, preizkus pa nikoli ne odkrije, ali je zaporedje ustvarilo predvideni zapis.

Zvestoba je del preizkusa

Pošten ugovor je: „Ponudnik ima preizkusno okolje; zakaj graditi še eno?“ Ponudnikovo preizkusno okolje uporabite, kadar podpira potrebni primer in ohranja podatke varne. Lokalna zamenjava upraviči svoj obstoj, ko potrebujete deterministične ponastavitve, namerne napake ali preizkus klicev, ki jih ponudnikovo okolje ne more pripraviti. Zahteva pa tudi vzdrževanje. Vsako modelirano pravilo je lahko napačno ali zastari.

Uradna dokumentacija API za stike Brevo pravi, da morajo atributi stikov obstajati v računu, vrednosti napačnega deklariranega tipa pa se prezrejo. Zamenjava, ki zavrne vsako nepravilno oblikovano vrednost, bi se od tega dokumentiranega primera razlikovala. Agenta bi lahko naučila pričakovati napako, ki je nikoli ne bo.

Zapišite, katera vedenja ponudnika zamenjava pokriva. Ohranite majhen nabor preverjanj tehnične specifikacije proti pravemu API ali njegovemu podprtemu preizkusnemu okolju. Ko preverjanje odkrije razliko, posodobite zamenjavo in dodajte primer, ki jo je razkril. Simulacija je model ponudnika, ne njegova zamenjava.

Enaka disciplina velja za čas. Zamenjava, v kateri je vsak zapis takoj viden, lahko spregleda potek, ki ponovno bere prezgodaj. Zamenjava, ki vedno zadrži zapis, lahko izmisli napake, ki jih ponudnik ne povzroča. Modelirajte čas le tam, kjer vpliva na preizkušano odločitev, preostalo pa označite kot zunaj simulacije. Uspešen preizkus ima tedaj natančen pomen: agent je ta dejanja dokončal pod temi modeliranimi pravili.

Tajov vodnik za priključek Brevo isto praktično težavo opisuje s trgovčeve strani: uspešna zahteva lahko pusti polje prazno. Preizkus je koristen le, če preveri polje, ne zgolj odgovora HTTP.

Simuliran ciljni sistem ponastavljivo stanje znane napake

Preverjanja tehnične specifikacije primerjava ključnega vedenja beleženje razlik

Živi ciljni sistem nastavitve računa opaženo stanje

Simuliran ciljni sistem preizkusi agenta po modeliranih pravilih. Preverjanja tehnične specifikacije ta pravila primerjajo z živim sistemom pred omejenim predogledom.

Od varne vaje k omejenemu dokazu

Uspešni simulaciji naj sledi majhen predogled v živem sistemu. Izberite nekaj zapisov z izrecno določenim pričakovanim stanjem v ciljnem sistemu. Vključite običajen zapis, manjkajoče neobvezno polje in zapis, katerega stanje privolitve prepoveduje uporabo za trženje. Preverite, kaj ciljni sistem dejansko shrani. Rezultata ne sklepajte samo iz vsebine zahteve.

Sintetični predogled in preverjanje cilja odgovarjata na različni vprašanji. Predogled preslikave Tajo preizkusi pretvorbo brez zapisa v cilj. Predlagani prikaz dejavnosti spodaj pokaže naslednjo mejo: tudi izvedeno spremembo je treba preveriti v cilju. Zadnji korak ostane označen kot čakajoč, da vaje ne zamenjamo za dokaz.

TajoPonazoritev zasnove · Vzorčni podatki

Opravljen zapis še vedno potrebuje dokaz

Ali se je sinhronizacija strank končala?

Aplikacija Tajo MCPDejavnost

Zapis je bil izveden. Preverjanje še čaka.

Stanje v cilju še ni bilo preverjeno.

Dejavnost sinhronizacije

1. Zahteva sprejeta
2. Sprememba izvedena
3. Preverjanje cilja še čaka

Vzorčni zagon · 14:32 UTC

Kaj vemo

Odgovor ponudnika

Sprejeto

Rezultat zapisa

Izvedeno

Ponovno branje iz cilja

Čaka

Prikažite izvirni dogodek

Uspešen klic ne dokazuje končnega stanja.

Predlagani prikaz dokazov

Preglejte dejavnost

Predlagani prikaz temelji na toku dejavnosti Tajo. Ponazoritev doda stanje preverjanja; ne trdi, da je ponovno branje iz cilja že uvedeno.

Predogled naj ima ozek obseg in jasen pogoj za ustavitev. Neuspeh naj prepreči široko aktivacijo in pokaže na natančno neskladje: definicijo polja, identifikator, tip, dovoljenje ali čas. Uspešen predogled ne dokazuje, da se bodo vsi prihodnji zapisi obnašali enako, dokazuje pa, da tehnična specifikacija za izbrane primere danes deluje.

Zaporedje loči dve vprašanji. Simulacija sprašuje: „Ali agent sledi načrtovanemu pravilu, ko nadzorujemo svet?“ Živi predogled sprašuje: „Ali načrtovano pravilo ustreza temu računu pri ponudniku?“ Nobeno vprašanje ne more nadomestiti drugega.

Vodnik za obratni ETL pojasnjuje, zakaj se končna naloga ponavlja na veliko zapisih. To ponavljanje poveča vsako neskladje med simulirano in resnično tehnično specifikacijo.

Vadite v svetu, ki ga lahko ponastavite. Nato preglejte svet, ki ga ne morete.