Pe această pagină
Un test trecut poate ascunde o regulă lipsă. În acest caz ilustrativ, un agent trebuie să conecteze un magazin la o platformă de e-mail. Serverul de test acceptă actualizarea unui contact și întoarce un răspuns 200 curat. Agentul își termină sarcina, iar testul trece.
Destinația reală are o regulă în plus: atributul personalizat trebuie declarat înainte să poată fi setat prin actualizarea contactului. Serverul de test nu a modelat regula. Rezultatul său pozitiv dovedește ceva despre agent în lumea testului. Nu dovedește nimic despre regula absentă din lumea reală.
Acesta este compromisul central al simulării. Face repetabile acțiunile periculoase ori scumpe. Creează și un al doilea sistem, al cărui comportament se poate îndepărta de primul.
Un înlocuitor permite testarea acțiunilor
Pentru a testa un agent care acționează, dă-i un obiectiv, un mediu și o stare finală observabilă. O discuție sursă despre medii simulate pentru agenți descrie această structură pentru sarcini în browser și muncă bazată pe cunoștințe. Mediul îi permite verificatorului să compare ce a lăsat agentul cu un rezultat cunoscut drept corect.
Pentru o integrare, înlocuitorul poate oferi câteva operațiuni ale destinației: enumeră câmpurile, creează un contact, actualizează-l și citește-l din nou. Poate conține un set de test cu câmpul FNAME declarat și câmpul CUSTOM_TIER absent. Testul poate cere agentului să propună o mapare, apoi să respingă o scriere care folosește CUSTOM_TIER înainte să existe definiția lui.
Înlocuitorul este util fiindcă fiecare rulare începe din aceeași stare. Poți schimba pe rând o singură condiție: un câmp lipsă, o permisiune refuzată, o versiune veche de schemă sau un identificator ambiguu. Poți compara secvența de apeluri a agentului și starea rezultată între modele sau prompturi.
Este mai puternic decât o întrebare doar în text despre ce ar face agentul. Testează ce a apelat cu adevărat într-o lume controlată.
Dă setului de test o stare înainte și după fiecare apel, nu doar un răspuns pregătit. Dacă agentul creează contactul de două ori, al doilea apel ar trebui să arate comportamentul la duplicare pe care vrei să îl testezi. Dacă citește un câmp după scriere, citirea ar trebui să întoarcă starea stocată. Altfel, agentul poate trece testul trimițând o cerere plauzibilă, fără ca testul să descopere dacă secvența a produs înregistrarea dorită.
Fidelitatea face parte din test
Obiecția corectă este: „Furnizorul are un mediu de test; de ce să construim altul?” Folosește mediul furnizorului când suportă cazul necesar și păstrează datele în siguranță. Un înlocuitor local merită construit când ai nevoie de resetări deterministe, erori introduse intenționat sau o cale de a testa apeluri pe care mediul furnizorului nu le poate pregăti. Are și cost de întreținere. Fiecare regulă modelată poate fi greșită ori se poate învechi.
Documentația oficială pentru API-ul de contacte Brevo spune că atributele trebuie să existe în cont, iar valorile care nu respectă tipul declarat sunt ignorate. Un înlocuitor care respinge orice valoare malformată s-ar comporta altfel decât în acest caz documentat. Ar putea învăța agentul să aștepte o eroare care nu vine.
Notează ce comportamente ale furnizorului acoperă înlocuitorul. Păstrează câteva sonde ale contractului împotriva API-ului real sau a mediului de test acceptat de furnizor. Când o sondă găsește o diferență, actualizează înlocuitorul și adaugă cazul care a arătat-o. Simularea este un model al furnizorului, nu un substitut pentru el.
Aceeași disciplină se aplică timpului. Un înlocuitor care face vizibilă imediat fiecare scriere poate rata un flux care citește prea devreme. Unul care întârzie fiecare scriere poate inventa eșecuri inexistente la furnizor. Modelează timpii doar acolo unde afectează decizia testată și marchează restul în afara simulării. Un test trecut are atunci un sens precis: agentul a făcut aceste acțiuni în condițiile acestor reguli modelate.
Ghidul Tajo pentru conectorul Brevo descrie aceeași problemă practică din perspectiva comerciantului: o cerere reușită poate lăsa un câmp absent. Testul ajută numai dacă verifică acel câmp, nu doar răspunsul HTTP.
O destinație simulată testează agentul sub reguli modelate. Sondele de contract compară acele reguli cu destinația reală înaintea unei previzualizări limitate.
De la repetiția sigură la dovezi limitate
După o simulare reușită ar trebui să urmeze o mică previzualizare reală. Alege câteva înregistrări a căror stare așteptată în destinație este explicită. Include una obișnuită, una cu un câmp opțional lipsă și una a cărei stare de consimțământ interzice folosirea pentru marketing. Verifică ce stochează efectiv destinația. Nu deduce rezultatul numai din conținutul cererii.
O previzualizare sintetică și o verificare a destinației răspund la întrebări diferite. Previzualizarea mapării Tajo testează transformarea fără scrieri în destinație. Vizualizarea propusă de mai jos arată următoarea limită: chiar și o actualizare aplicată trebuie verificată în destinație. Ultimul pas rămâne în așteptare, ca repetiția să nu fie confundată cu dovada.
O scriere încheiată are încă nevoie de dovezi
S-a încheiat sincronizarea clienților?
Scrierea a fost aplicată. Verificarea este în așteptare.
Starea din destinație nu a fost încă verificată.
Activitatea sincronizării
- Cerere acceptată
- Actualizare aplicată
- Verificarea destinației este în așteptare
Rulare exemplificativă · 14:32 UTC
Ce știm
- Răspunsul furnizorului
- Acceptată
- Rezultatul scrierii
- Aplicată
- Recitire din destinație
- În așteptare
Un apel reușit nu dovedește starea finală.
Aspect propus bazat pe fluxul de activitate Tajo. Ilustrația adaugă o stare de verificare; nu afirmă că recitirea din destinație este deja implementată.
Previzualizarea ar trebui să aibă un domeniu îngust și o condiție clară de oprire. Un eșec ar trebui să împiedice activarea largă și să indice diferența exactă: definiția câmpului, identificatorul, tipul, permisiunea sau timpul. O previzualizare reușită nu dovedește că toate înregistrările viitoare se vor comporta la fel, dar stabilește că acel contract funcționează pentru cazurile alese astăzi.
Secvența separă două întrebări. Simularea întreabă: „Urmează agentul regula proiectată când controlăm lumea?” Previzualizarea reală întreabă: „Se potrivește regula proiectată acestui cont al furnizorului?” Niciuna nu o poate înlocui pe cealaltă.
Ghidul reverse ETL explică de ce sarcina finală se repetă pentru multe înregistrări. Repetiția amplifică orice nepotrivire rămasă între contractul simulat și cel real.
Exersează într-o lume pe care o poți reseta. Apoi examinează lumea pe care nu o poți reseta.
Întrebări Frecvente
Ce poate testa o destinație simulată?
Poate testa dacă agentul alege apelurile așteptate, respectă permisiunile, gestionează erorile cunoscute și lasă starea așteptată în simulare.
Ce nu poate dovedi?
Nu poate stabili că modelul său al furnizorului este complet. Comportamentul nedocumentat, timpii și configurarea specifică unui cont pot fi diferite de simulare.
Ce ar trebui să urmeze după o simulare reușită?
Rulează o previzualizare limitată sau un test restrâns în destinația reală, apoi examinează starea rezultată înainte de activarea largă.