På denne siden
En grønn test kan skjule en regel som mangler. I dette tenkte tilfellet blir en agent bedt om å koble en butikk til en e-postplattform. En testserver godtar en kontaktoppdatering og returnerer en pen 200. Agenten fullfører oppgaven, og testen består.
Det virkelige målsystemet har én regel til: Det egendefinerte attributtet må være opprettet før en kontaktoppdatering kan gi det en verdi. Testserveren modellerte ikke regelen. Det grønne resultatet beviser noe om agenten i testverdenen. Det beviser ingenting om den manglende regelen i drift.
Dette er simuleringens grunnleggende byttehandel. Den gjør farlige eller dyre handlinger mulig å gjenta. Samtidig skaper den et ekstra system som kan utvikle seg bort fra det første.
Et testmiljø gjør handlingstester mulige
For å teste en agent som handler, gi den et mål, et miljø og en sluttilstand som kan observeres. En kildediskusjon om simulerte agentmiljøer beskriver denne strukturen for nettleseroppgaver og kunnskapsarbeid. Miljøet lar en kontroll sammenligne det agenten etterlot, med et kjent riktig resultat.
For en integrasjon kan testmiljøet tilby et lite sett med operasjoner i målsystemet: list felt, opprett en kontakt, oppdater en kontakt og les den tilbake. Det kan ha et testgrunnlag med et opprettet FNAME-felt og et manglende CUSTOM_TIER-felt. En test kan be agenten foreslå en mapping og deretter avvise en oppdatering som bruker CUSTOM_TIER før feltet er opprettet.
Testmiljøet er nyttig fordi hver kjøring starter fra samme tilstand. Du kan endre én betingelse om gangen: et manglende felt, en avvist tillatelse, en gammel skjemaversjon eller en tvetydig identifikator. Du kan sammenligne agentens rekkefølge av kall og sluttresultatet på tvers av modeller eller prompter.
Det er sterkere enn et rent tekstspørsmål om hva agenten ville gjort. Det tester hvilke kall den faktisk gjorde i en kontrollert verden.
Gi testgrunnlaget en tilstand før og etter hvert kall, ikke bare et standardsvar. Hvis agenten oppretter en kontakt to ganger, bør det andre kallet vise atferden ved duplikater som du vil teste. Hvis den leser et felt etter skriving, bør lesingen returnere lagret tilstand. Ellers kan agenten bestå ved å sende en plausibel forespørsel uten at testen oppdager om rekkefølgen skapte den tilsiktede posten.
Test også hvor tro simuleringen er mot virkeligheten
En rimelig innvending er: «Leverandøren har et testmiljø. Hvorfor bygge et til?» Bruk leverandørens miljø når det støtter tilfellet du trenger, og holder data trygge. Et lokalt testmiljø fortjener plassen sin når du trenger samme starttilstand hver gang, planlagte feil eller en måte å teste kall som leverandørens testmiljø ikke kan sette opp. Det krever også vedlikehold. Hver regel du modellerer, kan være feil eller bli gammel.
Den offisielle Brevo-referansen for kontakter sier at kontaktattributter må finnes på kontoen, og at verdier med feil type i forhold til definisjonen blir ignorert. Et testmiljø som avviser hver feil verdi, ville oppføre seg annerledes enn dette dokumenterte tilfellet. Det kan lære agenten å vente på en feil som aldri kommer.
Skriv ned hvilken leverandøratferd testmiljøet dekker. Hold et lite sett med kontraktssjekker mot det virkelige API-et eller leverandørens støttede testmiljø. Når en sjekk finner en forskjell, oppdater simuleringen og legg til tilfellet som avslørte forskjellen. Simuleringen er en modell av leverandøren, ikke en erstatning for leverandøren.
Samme disiplin gjelder tid. Et testmiljø som gjør hver skriving synlig umiddelbart, kan overse en arbeidsflyt som leser for tidlig. Et testmiljø som forsinker hver skriving, kan finne på feil leverandøren ikke har. Modeller tidsforløp bare der det påvirker beslutningen som testes, og merk resten som utenfor simuleringen. En bestått test får da en presis betydning: Denne agenten fullførte disse handlingene under disse modellerte reglene.
Tajos guide til Brevo-koblingen beskriver samme praktiske problem fra butikkens side: En vellykket forespørsel kan ende med at et felt mangler. En test er nyttig bare hvis den kontrollerer feltet, ikke bare HTTP-svaret.
Et simulert målsystem tester agenten under modellerte regler. Kontraktssjekker sammenligner reglene med virkelig drift før en avgrenset forhåndsvisning.
Gå fra trygg øving til avgrenset bevis
En bestått simulering bør følges av en liten forhåndsvisning i det virkelige systemet. Velg noen få poster der forventet tilstand i målsystemet er tydelig. Ta med en vanlig post, en post uten et valgfritt felt og en post der samtykket forbyr bruk til markedsføring. Sjekk hva målsystemet faktisk lagrer. Ikke utled resultatet bare fra dataene som ble sendt.
En syntetisk forhåndsvisning og en målkontroll svarer på ulike spørsmål. Tajos kartleggingsforhåndsvisning tester en oversettelse uten å skrive til målsystemet. Den foreslåtte aktivitetsvisningen viser neste grense: Selv en utført oppdatering må kontrolleres i målsystemet. Når dette steget står som ventende, blir ikke øvelsen forvekslet med bevis.
En fullført skriving trenger fortsatt bevis
Ble kundesynkroniseringen fullført?
Skriving utført. Verifisering venter.
Tilstanden i målsystemet er ikke kontrollert ennå.
Synkroniseringsaktivitet
- Forespørsel godtatt
- Oppdatering utført
- Målkontroll venter
Eksempelkjøring · 14:32 UTC
Det vi vet
- Leverandørens svar
- Godtatt
- Skriveresultat
- Utført
- Tilbakelesing fra målsystemet
- Venter
Et vellykket kall beviser ikke sluttilstanden.
Foreslått utforming inspirert av Tajos aktivitetslogg. Illustrasjonen legger til en verifiseringstilstand; den hevder ikke at tilbakelesing fra målsystemet allerede er implementert.
Forhåndsvisningen bør ha et smalt omfang og en tydelig stoppregel. En feil bør hindre bred aktivering og vise nøyaktig hvor avviket ligger: feltdefinisjon, identifikator, type, tillatelse eller tidsforløp. En bestått forhåndsvisning beviser ikke at alle fremtidige poster vil oppføre seg likt, men den viser at kontrakten virker for de utvalgte tilfellene i dag.
Rekkefølgen skiller mellom to spørsmål. Simuleringen spør: «Følger agenten regelen vi har laget, når vi kontrollerer verden?» Den virkelige forhåndsvisningen spør: «Passer regelen til denne leverandørkontoen?» Ingen av spørsmålene kan erstatte det andre.
Guiden til reverse ETL forklarer hvorfor sluttjobben gjentas for mange poster. Gjentakelsen forstørrer ethvert avvik som er igjen mellom den simulerte og den virkelige kontrakten.
Øv i en verden du kan nullstille. Undersøk så verdenen du ikke kan nullstille.
Ofte Stilte Spørsmål
Hva kan et simulert målsystem teste?
Det kan teste om en agent velger forventede kall, respekterer tillatelser, håndterer kjente feil og etterlater forventet tilstand inne i simuleringen.
Hva kan det ikke bevise?
Det kan ikke vise at modellen av leverandøren er fullstendig. Udokumentert atferd, tidsforløp og kontospesifikk konfigurasjon kan avvike fra simuleringen.
Hva bør følge etter en bestått simulering?
Kjør en avgrenset forhåndsvisning eller en liten prøve mot det virkelige målsystemet, og undersøk deretter sluttresultatet før bred aktivering.