Na ovoj stranici
Zeleni test može skrivati pravilo koje nedostaje. U ovom ilustrativnom slučaju agent treba povezati trgovinu s platformom e-pošte. Testni poslužitelj prihvati ažuriranje kontakta i vrati uredan 200. Agent završi zadatak i test prođe.
Stvarno odredište ima još jedno pravilo: prilagođeni atribut mora biti deklariran prije nego što ga ažuriranje kontakta može postaviti. Testni poslužitelj nije modelirao to pravilo. Njegov zeleni rezultat dokazuje nešto o agentu u testnom svijetu. Ne dokazuje ništa o pravilu koje nedostaje u živom svijetu.
To je osnovna pogodba simulacije. Opasne ili skupe radnje čini ponovljivima. Ujedno stvara drugi sustav čije ponašanje može odstupiti od prvoga.
Zamjena omogućuje testiranje radnji
Da biste testirali agenta koji djeluje, dajte mu cilj, okruženje i vidljivo završno stanje. Izvorna rasprava o simuliranim okruženjima agenata opisuje tu strukturu za zadatke u pregledniku i uredski rad. Okruženje omogućuje verifikatoru usporediti ono što je agent ostavio s poznatim ispravnim rezultatom.
Za integraciju zamjena može izložiti mali skup odredišnih operacija: popis polja, stvaranje kontakta, ažuriranje kontakta i njegovo ponovno čitanje. Može držati testno stanje s deklariranim poljem FNAME i odsutnim poljem CUSTOM_TIER. Test može tražiti od agenta da predloži mapiranje, a zatim odbiti zapisivanje s CUSTOM_TIER prije nego što postoji definicija.
Zamjena je korisna jer svako izvođenje počinje iz istog stanja. Možete promijeniti jedan uvjet: nedostajuće polje, odbijeno dopuštenje, zastarjelu verziju sheme ili dvosmislen identifikator. Zatim usporediti redoslijed agentovih poziva i dobiveno stanje kroz modele ili upute.
To je jače od tekstualnog pitanja što bi agent učinio. Provjerava što je stvarno pozvao u kontroliranom svijetu.
Dajte testnom stanju stanje prije i poslije svakog poziva, ne samo unaprijed pripremljen odgovor. Ako agent dvaput stvori kontakt, drugi poziv treba pokazati ponašanje s duplikatom koje želite ispitati. Ako nakon zapisivanja čita polje, čitanje treba vratiti pohranjeno stanje. Inače agent može proći slanjem uvjerljivog zahtjeva, a test nikad ne otkrije je li slijed proizveo željeni zapis.
Vjernost je dio testa
Pošten prigovor glasi: „Dobavljač ima testno okruženje. Zašto graditi drugo?” Koristite dobavljačevo okruženje kada podržava potreban slučaj i čuva podatke. Lokalna zamjena opravdana je kada trebate determinističko vraćanje početnog stanja, namjerne pogreške ili način ispitivanja poziva koje dobavljačevo okruženje ne može postaviti. Ona ima i trošak održavanja. Svako modelirano pravilo može biti pogrešno ili zastarjeti.
Službeni Brevo API za kontakte kaže da atributi kontakta moraju postojati u računu, a vrijednosti pogrešne deklarirane vrste se zanemaruju. Zamjena koja odbija svaku loše oblikovanu vrijednost ponašala bi se drukčije od tog dokumentiranog slučaja. Mogla bi naučiti agenta da očekuje pogrešku koja neće stići.
Zapišite koja ponašanja dobavljača zamjena pokriva. Držite mali skup ugovornih proba prema stvarnom API-ju ili njegovu podržanom testnom okruženju. Kad proba pronađe razliku, ažurirajte zamjenu i dodajte slučaj koji ju je otkrio. Simulacija je model dobavljača, ne njegova zamjena.
Ista disciplina vrijedi za vrijeme. Zamjena u kojoj je svako zapisivanje odmah vidljivo može propustiti tijek koji čita prerano. Zamjena koja odgađa svako zapisivanje može izmisliti pogreške koje dobavljač ne stvara. Modelirajte vrijeme samo kada utječe na odluku pod testom, a ostalo označite kao izvan simulacije. Uspješan test tada ima precizno značenje: agent je obavio te radnje pod tim modeliranim pravilima.
Tajov vodič za Brevo poveznik opisuje istu praktičnu teškoću sa strane trgovca: uspješan zahtjev može ostaviti polje praznim. Test vrijedi samo ako provjerava polje, ne samo HTTP odgovor.
Simulirano odredište testira agenta pod modeliranim pravilima. Ugovorne probe uspoređuju ta pravila sa stvarnim odredištem prije ograničenog pregleda.
Od sigurne probe do ograničenog dokaza
Uspješna simulacija treba voditi do malog pregleda u stvarnom sustavu. Odaberite nekoliko zapisa s izričito očekivanim stanjima odredišta. Uključite običan zapis, nedostajuće neobvezno polje i zapis čije stanje privole zabranjuje marketinšku uporabu. Provjerite što odredište stvarno sprema. Ne zaključujte rezultat samo iz zahtjeva.
Sintetički pregled i provjera odredišta odgovaraju na različita pitanja. Pregled mapiranja Tajo ispituje pretvorbu bez upisa u odredište. Predloženi prikaz aktivnosti u nastavku pokazuje sljedeću granicu: i primijenjenu promjenu treba provjeriti u odredištu. Posljednji korak ostaje na čekanju kako se proba ne bi zamijenila s dokazom.
Dovršen upis i dalje treba dokaz
Je li sinkronizacija kupaca završila?
Upis je primijenjen. Provjera je na čekanju.
Stanje u odredištu još nije provjereno.
Aktivnost sinkronizacije
- Zahtjev prihvaćen
- Promjena primijenjena
- Provjera odredišta na čekanju
Primjerno izvođenje · 14:32 UTC
Što znamo
- Odgovor pružatelja usluge
- Prihvaćeno
- Rezultat upisa
- Primijenjeno
- Ponovno čitanje iz odredišta
- Na čekanju
Uspješan poziv ne dokazuje konačno stanje.
Predloženi prikaz temelji se na tijeku aktivnosti Tajo. Ilustracija dodaje stanje provjere; ne tvrdi da je ponovno čitanje iz odredišta već implementirano.
Pregled treba imati uzak opseg i jasan uvjet zaustavljanja. Pogreška treba spriječiti široku aktivaciju i pokazati točnu razliku: definiciju polja, identifikator, vrstu, dopuštenje ili vrijeme. Uspješan pregled ne dokazuje da će se svi budući zapisi ponašati isto, ali potvrđuje da ugovor danas radi za odabrane slučajeve.
Taj slijed razdvaja dva pitanja. Simulacija pita: „Slijedi li agent projektirano pravilo kada kontroliramo svijet?” Stvarni pregled pita: „Odgovara li projektirano pravilo ovom računu dobavljača?” Nijedno pitanje ne zamjenjuje drugo.
Vodič za obrnuti ETL objašnjava zašto se završni posao ponavlja na mnogo zapisa. Ponavljanje povećava svaku razliku koja ostane između simuliranog i stvarnog ugovora.
Vježbajte u svijetu koji možete vratiti na početak. Zatim pregledajte svijet koji ne možete.
Često postavljana pitanja
Što simulirano odredište može testirati?
Može testirati bira li agent očekivane pozive, poštuje li ovlasti, obrađuje li poznate pogreške i ostavlja li očekivano stanje u simulaciji.
Što ne može dokazati?
Ne može potvrditi da je njegov model dobavljača potpun. Nedokumentirano ponašanje, vrijeme i postavke pojedinog računa mogu se razlikovati od simulacije.
Što slijedi nakon uspješne simulacije?
Pokrenite ograničen pregled ili canary na stvarnom odredištu, pa pregledajte dobiveno stanje prije šire aktivacije.