Di halaman ini
Hasil uji hijau dapat menyembunyikan aturan yang hilang. Dalam kasus ilustratif ini, agen diminta menghubungkan toko ke platform email. Server uji menerima pembaruan kontak dan mengembalikan 200. Agen menyelesaikan tugasnya dan uji dinyatakan berhasil.
Sistem tujuan nyata mempunyai satu aturan tambahan: atribut kustom harus dideklarasikan sebelum pembaruan kontak dapat mengisinya. Server uji tidak memodelkan aturan itu. Hasil hijaunya membuktikan sesuatu tentang agen di dunia uji, tetapi tidak membuktikan aturan yang hilang di dunia nyata.
Inilah pertukaran utama dalam simulasi. Simulasi membuat tindakan yang berbahaya atau mahal dapat diulang dengan aman. Namun, simulasi juga menciptakan sistem kedua yang perilakunya dapat menyimpang dari sistem pertama.
Pengganti memungkinkan pengujian tindakan
Untuk menguji agen yang bertindak, berikan tujuan, lingkungan, dan keadaan akhir yang dapat diamati. Diskusi sumber tentang lingkungan simulasi bagi agen menguraikan struktur ini untuk tugas browser dan pekerjaan pengetahuan. Lingkungan memungkinkan pemeriksa membandingkan keadaan yang ditinggalkan agen dengan hasil yang diketahui benar.
Untuk integrasi, pengganti dapat menyediakan sedikit operasi tujuan: menampilkan daftar bidang, membuat kontak, memperbarui kontak, dan membacanya kembali. Ia dapat menyimpan data uji dengan bidang FNAME yang sudah dideklarasikan dan bidang CUSTOM_TIER yang belum ada. Pengujian dapat meminta agen mengusulkan pemetaan, lalu menolak penulisan yang memakai CUSTOM_TIER sebelum definisinya tersedia.
Pengganti berguna karena setiap eksekusi dimulai dari keadaan yang sama. Anda dapat mengubah satu kondisi pada satu waktu: bidang hilang, izin ditolak, versi skema usang, atau pengenal ambigu. Urutan panggilan agen dan keadaan hasilnya kemudian dapat dibandingkan antar model atau prompt.
Ini lebih kuat daripada pertanyaan teks tentang apa yang akan dilakukan agen. Pengujian ini melihat panggilan yang benar-benar dibuat agen dalam dunia yang terkendali.
Berikan keadaan sebelum dan sesudah setiap panggilan pada data uji, bukan hanya jawaban yang sudah disiapkan. Jika agen membuat kontak dua kali, panggilan kedua harus memperlihatkan perilaku duplikasi yang hendak diuji. Jika agen membaca bidang setelah menulisnya, pembacaan harus mengembalikan keadaan yang tersimpan. Jika tidak, agen dapat lulus hanya dengan mengirim permintaan yang tampak masuk akal, sementara pengujian tak pernah mengetahui apakah urutannya menghasilkan catatan yang dimaksud.
Kesetiaan simulasi merupakan bagian dari pengujian
Keberatan yang wajar adalah: “Penyedia sudah memiliki lingkungan uji; mengapa membuat yang lain?” Gunakan lingkungan penyedia ketika mendukung kasus yang diperlukan dan menjaga data tetap aman. Pengganti lokal pantas dibuat ketika Anda membutuhkan pengaturan ulang yang deterministik, kegagalan yang disengaja, atau panggilan yang tidak dapat disiapkan di lingkungan uji penyedia. Ia juga memerlukan pemeliharaan. Setiap aturan yang dimodelkan bisa keliru atau menjadi usang.
API kontak Brevo resmi menyatakan bahwa atribut kontak harus ada dalam akun dan nilai yang tidak sesuai dengan tipe yang dideklarasikan diabaikan. Pengganti yang menolak setiap nilai salah bentuk akan berperilaku berbeda dari kasus yang didokumentasikan itu. Ia dapat membuat agen mengharapkan kesalahan yang tidak pernah datang.
Catat perilaku penyedia mana yang dicakup pengganti. Pertahankan sejumlah kecil pengujian kontrak terhadap API nyata atau lingkungan uji resmi. Ketika pengujian menemukan perbedaan, perbarui pengganti dan tambahkan kasus yang mengungkapnya. Simulasi adalah model penyedia, bukan penggantinya.
Disiplin yang sama berlaku untuk waktu. Pengganti yang membuat semua penulisan langsung terlihat dapat melewatkan alur yang membaca terlalu cepat. Pengganti yang menunda semua penulisan dapat mengarang kegagalan yang tidak terjadi pada penyedia. Modelkan waktu hanya ketika memengaruhi keputusan yang diuji, dan tandai bagian lain sebagai di luar simulasi. Dengan demikian, uji yang lulus mempunyai arti tepat: agen ini menyelesaikan tindakan tersebut menurut aturan yang dimodelkan ini.
Panduan konektor Brevo dari Tajo menjelaskan masalah praktis serupa dari sisi toko: permintaan yang berhasil bisa meninggalkan bidang tetap kosong. Pengujian hanya membantu jika ia memeriksa bidang, bukan sekadar respons HTTP.
Sistem tujuan simulasi menguji agen menurut aturan yang dimodelkan. Pengujian kontrak membandingkan aturan itu dengan tujuan nyata sebelum pratinjau terbatas.
Dari latihan aman ke bukti terbatas
Simulasi yang lulus seharusnya diikuti pratinjau kecil pada sistem nyata. Pilih beberapa catatan dengan keadaan tujuan yang diharapkan secara jelas. Sertakan catatan rutin, catatan tanpa bidang opsional, dan catatan dengan status persetujuan yang melarang penggunaan untuk pemasaran. Verifikasi apa yang benar-benar disimpan sistem tujuan. Jangan menyimpulkan hasil hanya dari isi permintaan.
Pratinjau sintetis dan pemeriksaan tujuan menjawab pertanyaan berbeda. Pratinjau pemetaan Tajo menguji transformasi tanpa menulis ke tujuan. Tampilan usulan di bawah menunjukkan batas berikutnya: pembaruan yang diterapkan masih memerlukan pemeriksaan keadaan tujuan. Status tertunda mencegah latihan disangka bukti.
Penulisan yang selesai tetap memerlukan bukti
Apakah sinkronisasi pelanggan selesai?
Penulisan diterapkan. Verifikasi tertunda.
Keadaan di tujuan belum diperiksa.
Aktivitas sinkronisasi
- Permintaan diterima
- Pembaruan diterapkan
- Pemeriksaan tujuan tertunda
Proses contoh · 14:32 UTC
Yang diketahui
- Respons penyedia
- Diterima
- Hasil penulisan
- Diterapkan
- Baca ulang dari tujuan
- Tertunda
Panggilan berhasil tidak membuktikan keadaan akhir.
Tata letak yang diusulkan berdasarkan umpan aktivitas Tajo. Ilustrasi ini menambahkan status verifikasi; fitur baca ulang tujuan belum dinyatakan tersedia.
Pratinjau perlu cakupan sempit dan kondisi berhenti yang jelas. Kegagalan harus mencegah aktivasi luas dan menunjuk perbedaan tepat: definisi bidang, pengenal, tipe, izin, atau waktu. Pratinjau yang lulus tidak membuktikan bahwa setiap catatan masa depan akan berperilaku sama, tetapi menunjukkan bahwa kontrak bekerja hari ini untuk kasus yang dipilih.
Urutan ini memisahkan dua pertanyaan. Simulasi bertanya, “Apakah agen mengikuti aturan rancangan saat kita mengendalikan dunianya?” Pratinjau nyata bertanya, “Apakah aturan rancangan sesuai dengan akun penyedia ini?” Salah satu pertanyaan tidak dapat menggantikan yang lain.
Panduan reverse ETL menjelaskan mengapa pekerjaan akhir berulang di banyak catatan. Pengulangan memperbesar setiap perbedaan yang masih ada antara kontrak simulasi dan kontrak nyata.
Berlatihlah di dunia yang dapat Anda atur ulang. Lalu periksa dunia yang tidak dapat Anda atur ulang.
Pertanyaan yang sering diajukan
Apa yang dapat diuji oleh sistem tujuan simulasi?
Simulasi dapat menguji apakah agen memilih panggilan yang diharapkan, menghormati izin, menangani kesalahan yang diketahui, dan meninggalkan keadaan yang diharapkan di dalam simulasi.
Apa yang tidak dapat dibuktikannya?
Simulasi tidak dapat membuktikan bahwa modelnya tentang penyedia sudah lengkap. Perilaku yang tidak didokumentasikan, waktu pemrosesan, dan konfigurasi khusus akun dapat berbeda dari simulasi.
Apa langkah setelah simulasi berhasil?
Jalankan pratinjau atau uji terbatas pada sistem tujuan yang nyata, lalu periksa keadaan hasilnya sebelum mengaktifkan integrasi secara luas.