Na ovoj stranici
Zelen test može sakriti pravilo koje nedostaje. U ovom ilustrativnom slučaju agent treba da poveže prodavnicu sa platformom za imejl. Test server prihvata izmenu kontakta i vraća uredan odgovor 200. Agent završava zadatak i test prolazi.
Stvarno odredište ima dodatno pravilo: prilagođeni atribut mora biti deklarisan pre nego što ga izmena kontakta može postaviti. Test server to pravilo nije modelovao. Njegov zelen rezultat dokazuje nešto o agentu u test svetu. Ne dokazuje ništa o nedostajućem pravilu u živom svetu.
To je osnovna pogodba simulacije. Opasne ili skupe radnje čini ponovljivim. Istovremeno stvara drugi sistem čije ponašanje može odstupati od prvog.
Zamena omogućava testiranje radnji
Da biste testirali agenta koji deluje, dajte mu cilj, okruženje i vidljivo konačno stanje. Rasprava o simuliranim okruženjima za agente opisuje ovu strukturu za zadatke u pregledaču i radu sa znanjem. Okruženje omogućava sistemu za proveru da poredi ono što je agent ostavio sa poznatim ispravnim rezultatom.
Za integraciju zamena može ponuditi mali skup operacija odredišta: izlistavanje polja, stvaranje kontakta, izmenu kontakta i ponovno čitanje. Može držati testne podatke sa deklarisanim poljem FNAME i odsutnim CUSTOM_TIER. Test može od agenta tražiti predlog mapiranja, pa odbiti upis koji koristi CUSTOM_TIER pre nego što postoji definicija.
Zamena je korisna jer svako izvršavanje počinje iz istog stanja. Možete menjati po jedan uslov: polje koje nedostaje, odbijenu dozvolu, zastarelu verziju šeme, nejasan identifikator. Možete porediti niz agentovih poziva i dobijeno stanje među modelima ili promptovima.
To je jače od tekstualnog pitanja šta bi agent uradio. Testira šta je zaista pozvao u kontrolisanom svetu.
Testnim podacima dajte stanje pre i posle svakog poziva, ne samo pripremljen odgovor. Ako agent dva puta stvori kontakt, drugi poziv treba da pokaže ponašanje sa duplikatom koje želite da testirate. Ako polje pročita posle upisa, čitanje treba da vrati sačuvano stanje. U suprotnom agent može proći slanjem ubedljivog zahteva, a test nikada ne otkrije da li je niz stvorio željeni zapis.
Vernost je deo testa
Pošten prigovor je: „Dobavljač ima test okruženje; zašto praviti još jedno?“ Koristite dobavljačevo test okruženje kada podržava slučaj koji vam treba i čuva podatke. Lokalna zamena opravdana je kada trebaju deterministička resetovanja, namerne greške ili test poziva koje okruženje dobavljača ne može da pripremi. Ali košta održavanja. Svako modelovano pravilo može biti pogrešno ili zastareti.
Zvanični Brevo API za kontakte kaže da atributi kontakta moraju postojati u nalogu, a vrednosti pogrešnog deklarisanog tipa se zanemaruju. Zamena koja odbija svaku nepravilnu vrednost ponašala bi se drugačije od tog dokumentovanog slučaja. Mogla bi naučiti agenta da očekuje grešku koja neće stići.
Zapišite koja ponašanja dobavljača zamena pokriva. Održavajte mali skup provera ugovora prema stvarnom API-ju ili podržanom test okruženju. Kada provera nađe razliku, ažurirajte zamenu i dodajte slučaj koji ju je otkrio. Simulacija je model dobavljača, ne zamena za dobavljača.
Ista disciplina važi za vreme. Zamena koja svaki upis čini odmah vidljivim može propustiti tok koji čita prerano. Zamena koja svaki upis kasni može izmisliti greške koje dobavljač nema. Modelujte vreme samo tamo gde utiče na odluku koju testirate, a ostalo označite kao van simulacije. Uspešan test tada ima precizno značenje: ovaj agent je završio ove radnje pod ovim modelovanim pravilima.
Tajo vodič za Brevo konektor opisuje isti praktičan problem iz ugla trgovca: uspešan zahtev može ostaviti polje prazno. Test vredi samo ako proveri polje, ne samo HTTP odgovor.
Simulirano odredište testira agenta prema modelovanim pravilima. Provere ugovora porede ta pravila sa živim odredištem pre ograničenog pregleda.
Od bezbedne probe do ograničenog dokaza
Posle uspešne simulacije treba da sledi mali pregled u živom sistemu. Izaberite nekoliko zapisa sa izričito navedenim očekivanim stanjima. Uključite običan zapis, neobavezno polje koje nedostaje i zapis čije stanje saglasnosti zabranjuje marketinšku upotrebu. Proverite šta odredište zaista čuva. Ne zaključujte samo iz sadržaja zahteva.
Sintetički pregled i provera odredišta odgovaraju na različita pitanja. Pregled mapiranja Tajo ispituje pretvaranje bez upisa u odredište. Predloženi prikaz aktivnosti ispod pokazuje sledeću granicu: i primenjenu izmenu treba proveriti u odredištu. Poslednji korak ostaje na čekanju da se proba ne zameni dokazom.
Završen upis i dalje traži dokaz
Da li je sinhronizacija kupaca završena?
Upis je primenjen. Provera je na čekanju.
Stanje u odredištu još nije provereno.
Aktivnost sinhronizacije
- Zahtev prihvaćen
- Izmena primenjena
- Provera odredišta na čekanju
Primer izvršavanja · 14:32 UTC
Šta znamo
- Odgovor dobavljača
- Prihvaćeno
- Rezultat upisa
- Primenjeno
- Ponovno čitanje iz odredišta
- Na čekanju
Uspešan poziv ne dokazuje konačno stanje.
Predloženi prikaz zasniva se na toku aktivnosti Tajo. Ilustracija dodaje stanje provere; ne tvrdi da je ponovno čitanje iz odredišta već implementirano.
Pregled treba da ima uzak opseg i jasan uslov za zaustavljanje. Neuspeh treba da spreči široku aktivaciju i pokaže tačnu razliku: definiciju polja, identifikator, tip, dozvolu ili vreme. Uspešan pregled ne dokazuje da će se svi budući zapisi ponašati isto, ali potvrđuje da ugovor danas radi za izabrane slučajeve.
Ovaj redosled razdvaja dva pitanja. Simulacija pita: „Da li agent sledi osmišljeno pravilo dok kontrolišemo svet?“ Živi pregled pita: „Da li osmišljeno pravilo odgovara ovom nalogu kod dobavljača?“ Nijedno pitanje ne zamenjuje drugo.
Vodič za obrnuti ETL objašnjava zašto se konačni posao ponavlja na mnogim zapisima. To ponavljanje uvećava svaku razliku između simuliranog i stvarnog ugovora.
Vežbajte u svetu koji možete resetovati. Zatim pregledajte svet koji ne možete.
Često Postavljana Pitanja
Šta simulirano odredište može da testira?
Može proveriti da li agent bira očekivane pozive, poštuje dozvole, obrađuje poznate greške i ostavlja očekivano stanje unutar simulacije.
Šta ne može da dokaže?
Ne može utvrditi da je njegov model dobavljača potpun. Nedokumentovano ponašanje, vreme i podešavanja pojedinačnog naloga mogu se razlikovati od simulacije.
Šta sledi posle uspešne simulacije?
Pokrenite ograničen pregled ili probno izvršavanje u stvarnom odredištu, pa proverite dobijeno stanje pre široke aktivacije.