Trae adalah sebuah perulangan. Agen Builder-nya membaca repositori Anda, mengedit file, menjalankan perintah di terminal, dan membaca output untuk memutuskan apa yang harus dilakukan selanjutnya. Jadi, mengapa tes API Anda tidak ada dalam perulangan itu? Mereka ada di Apidog di balik GUI dan berjalan ketika seseorang ingat untuk mengklik. Agen Anda tidak pernah menyentuhnya.
Perbaikannya adalah satu blok konfigurasi. Apidog CLI adalah paket npm, apidog-cli, yang menjalankan skenario pengujian yang Anda buat di Apidog langsung dari terminal. Setelah CLI terinstal dan Trae tahu keberadaannya, Builder menjalankan skenario Apidog dengan cara yang sama seperti menjalankan unit test Anda: jalankan perintah, baca kode keluar, perbaiki kode jika merah.
Jika Anda belum menginstal CLI, lakukan itu terlebih dahulu. Cara menginstal Apidog CLI dengan agen pengkodean AI menjelaskan instalasi npm, otentikasi, dan jalankan pertama, dengan agen yang melakukan pengetikan. Artikel ini mengasumsikan apidog --version mencetak angka dan akun Apidog Anda sudah terautentikasi.
Trae mana yang dimaksud
Trae adalah AI IDE milik ByteDance, dibangun di atas VS Code, dengan mode agen yang disebut Builder yang mengedit file dan menjalankan perintah terminal sendiri. Anda bisa membaca detail produknya di situs resmi Trae. Artikel ini membahas IDE desktop, bukan proyek penelitian trae-agent yang berdiri sendiri di GitHub. Jika Anda membuka Trae, melihat panel obrolan di samping editor Anda, dan bisa mengganti agen ke Builder, Anda berada di tempat yang tepat.
Perbedaan ini penting karena Trae memiliki caranya sendiri untuk mempelajari aturan proyek, dan mekanisme itu mengubah “jalankan tes saya” yang sekali jalan menjadi sesuatu yang dilakukan Builder sendiri. Mekanisme itu adalah file aturan proyek. Jika Anda ingin versi agnostik-alat dari alur kerja ini terlebih dahulu, panduan lengkap Apidog CLI mencakup CLI secara terpisah.
Langkah 1: Tambahkan file aturan proyek
Trae membaca file aturan sebelum Builder mulai bekerja. File tingkat proyek berada di .trae/rules/project_rules.md di root repositori Anda, sesuai dokumentasi aturan Trae. Agen memuat aturan-aturan ini selama inisialisasi dan menggunakannya saat menghasilkan dan mengedit kode. Ada juga user_rules.md tingkat pengguna yang berlaku di semua proyek Anda; untuk alur kerja ini, satu file proyek di root repo sudah cukup.
Buat .trae/rules/project_rules.md dan tambahkan blok pendek yang menamai CLI, perintah skenario yang tepat, dan aturan yang menjaga integritas Builder:
## Pengujian API dengan Apidog CLI
Ketika Anda mengubah kode yang menyentuh endpoint API, verifikasi dengan menjalankan
skenario pengujian Apidog, bukan hanya unit test.
Perintah:
apidog run -t <scenario_id> -e <env_id> -r cli
Aturan:
- `apidog run` keluar 0 ketika setiap pernyataan lulus dan non-nol pada setiap kegagalan.
Perlakukan kode keluar non-nol sebagai tes yang gagal, bahkan jika ringkasan terlihat baik-baik saja.
- Mesin ini sudah diautentikasi melalui `apidog login`. Jangan pernah menambahkan flag
--access-token dan jangan pernah meletakkan token di file ini.
- Jika sebuah flag tidak dikenal, jalankan `apidog run --help` dan gunakan flag yang tepat dari sana.
Inilah mengapa Anda menulis CLI ke dalam project_rules.md daripada menyebutkannya dalam obrolan. ID skenario yang diketik ke panel obrolan akan hilang saat sesi berakhir. Yang ada di .trae/rules/project_rules.md akan ada untuk setiap rekan tim dan setiap Builder dijalankan mulai sekarang. Trae juga membaca folder .trae/rules/ di subdirektori, sehingga monorepo dapat menyimpan aturan per-layanan di samping setiap layanan.
Langkah 2: Dapatkan perintah dari Apidog
Anda tidak perlu menebak perintahnya. Buka skenario pengujian di Apidog, buka tab CI/CD-nya, dan salin baris apidog run yang dihasilkan. Ini sudah memiliki ID skenario nyata setelah -t dan ID lingkungan setelah -e, jadi Anda menempelkan perintah yang Apidog tahu valid daripada mengarang ID secara manual.
Masukkan ID-ID tersebut ke dalam blok di .trae/rules/project_rules.md, menggantikan placeholder <scenario_id> dan <env_id>. Untuk daftar lengkap flag dan apa fungsi masing-masing, lihat referensi perintah apidog run.
Langkah 3: Minta Builder menjalankan pengujian
Dengan blok yang sudah ada, alihkan agen Trae ke Builder dan mulai di repo Anda. Builder memuat project_rules.md saat inisialisasi, jadi ia sudah tahu CLI ada di sana. Lakukan perubahan yang menyentuh API Anda, atau cukup minta untuk menjalankan pemeriksaan:
Jalankan skenario pengujian Apidog dan beri tahu saya kode keluarnya.
Builder mengeluarkan perintah apidog run dari file aturan Anda. Model persetujuan Trae penting di sini: ketika agen ingin menjalankan perintah shell, ia merekomendasikan perintah dan menampilkan tombol Run, dan perintah tersebut dieksekusi di terminal Trae hanya setelah Anda mengkliknya. Setelah berjalan, Builder secara otomatis membaca dan menganalisis output. Jadi Anda menyetujui apidog run sekali, dan agen mengambil hasilnya dari sana.
Reporter -r cli mencetak hasil langkah demi langkah dan ringkasan langsung di terminal, tempat Builder membaca setiap permintaan dan pernyataan saat terjadi. Anda ingin melihat eksekusi berjalan dan Builder melaporkan kembali ringkasan dan kode keluar.
Langkah 4: Baca laporan di dalam Trae
Ketika sebuah eksekusi gagal (merah), laporan memiliki jawabannya. Dengan -r cli, Builder mendapatkan rincian yang mudah dibaca di terminal Trae: setiap permintaan, setiap pernyataan, dan yang mana yang gagal dengan nilai yang diharapkan versus nilai sebenarnya. Pernyataan yang gagal menyebutkan bidang atau kode status yang tepat, yang biasanya cukup bagi Builder untuk menemukan perbaikan.
Untuk laporan yang dapat Anda buka di browser atau berikan kepada rekan tim, tambahkan reporter HTML:
apidog run -t <scenario_id> -e <env_id> -r cli,html
Reporter html menulis file mandiri ke ./apidog-reports. Pertahankan cli dalam daftar agar Builder tetap mendapatkan output inline yang dibacanya untuk memutuskan langkah selanjutnya. Untuk setiap reporter, termasuk format JSON dan JUnit yang diurai oleh dashboard CI, lihat panduan laporan pengujian Apidog CLI.
Pengujian Trae di dalam perulangannya sendiri
Intinya adalah apa yang terjadi ketika Anda berhenti bertanya dan Builder menjalankan skenario sendiri karena project_rules.md memberitahunya.
Bayangkan Builder mengedit handler yang membangun respons checkout. Perulangannya berubah: ia mengedit kode, lalu, alih-alih menyatakan kemenangan, ia menjalankan skenario Apidog Anda terhadap staging, membaca kode keluar, dan bertindak berdasarkan itu. Hijau, ia melanjutkan. Merah, ia membuka laporan, membaca pernyataan mana yang gagal (kode status, bidang yang hilang, nilai yang salah), mencoba perbaikan, dan menjalankan ulang. Tes API menjadi bagian dari perulangan edit-tes-perbaiki yang sama yang sudah digunakan Builder untuk menjalankan unit test Anda. Anda menulis satu instruksi dan Builder memasukkan perintah tersebut ke dalam cara kerjanya.
Ini adalah model delegasikan-lalu-verifikasi yang membuat alur kerja agen aman. Builder menjalankan perintah dan membaca hasilnya; Anda terus membuat skenario secara visual di Apidog dan memeriksa bahwa agen membaca kode keluar dengan jujur. Untuk pola yang lebih luas, lihat cara menggunakan agen AI untuk pengujian API dan alat uji Apidog AI.
Verifikasi Trae benar-benar menjalankan CLI
Agen melaporkan keberhasilan yang tidak mereka peroleh, dan Builder tidak terkecuali. Tiga pemeriksaan, sesuai urutan seberapa sering mereka menemukan masalah.
Pertama, konfirmasikan bahwa perintah itu benar-benar dijalankan. Trae menunjukkan perintah yang dieksekusi Builder dan outputnya di terminal. Cari baris literal apidog run dan hasilnya di bawahnya. Jika Builder mengatakan itu menjalankan tes tetapi Anda tidak melihat perintahnya, itu meringkas sesuatu yang tidak pernah dilakukannya. Minta untuk menjalankan lagi dan tunjukkan output mentahnya.
Kedua, konfirmasikan kode keluar:
Berapa kode keluar dari perintah apidog run itu?
apidog run keluar 0 ketika setiap pernyataan lulus dan non-nol ketika ada yang gagal. Perilaku tunggal itu memungkinkan Builder, atau pipeline, memperlakukan eksekusi sebagai gerbang yang bersih. Ketika prosa Builder mengatakan "tes lulus" tetapi kode keluar non-nol, kode keluar itulah yang benar.
Ketiga, konfirmasikan ia menggunakan skenario yang sebenarnya. Jika sebuah eksekusi gagal dengan "skenario tidak ditemukan," Builder mungkin telah membuat atau salah mengingat ID. Periksa kembali nilai -t dan -e terhadap project_rules.md dan perintah yang dihasilkan Apidog di tab CI/CD. ID di file aturan Anda adalah kebenaran.
Opsional: hubungkan server Apidog MCP
Menjalankan apidog run dari project_rules.md mencakup sebagian besar yang Anda butuhkan. Menghubungkan server MCP selangkah lebih maju. Agen Trae bertindak sebagai klien MCP, sehingga Builder dapat memanggil alat yang diekspos oleh server MCP.
Untuk menambahkannya, buka pengaturan Trae, buka tab MCP, dan pilih server dari marketplace atau pilih Tambahkan Secara Manual dan tempel blok JSON dengan command, args, dan env server, sesuai panduan Trae untuk menambahkan server MCP. Server Apidog MCP mengekspos spesifikasi API Anda melalui MCP, sehingga Builder dapat membaca skema Anda saat menulis kode, bukan hanya setelah fakta. Pembagian kerja bersih: CLI menjalankan tes, dan MCP memberi agen spesifikasi.
Ketika Trae salah
Beberapa kegagalan sering muncul selama pengaturan.
Ini mengabaikan file aturan. Jika Builder menjalankan perintah generik atau tidak sama sekali, file tersebut mungkin tidak dimuat. Pastikan itu ada di .trae/rules/project_rules.md di root repositori Anda dan folder tersebut dinamakan rules, bukan rule. Memulai ulang sesi memaksa pembacaan ulang aturan.
Itu tetap meneruskan token akses. Jika Builder mencoba menambahkan --access-token, itu berarti ia menebak dari contoh publik. Blok tersebut sudah memberitahunya untuk tidak melakukannya, karena mesin sudah diautentikasi melalui apidog login. Tegaskan baris tersebut, dan jangan pernah meletakkan token asli di project_rules.md. Untuk bagaimana CLI menangani kredensial dalam penggunaan interaktif dan di CI, lihat otentikasi Apidog CLI.
Itu membuat flag sendiri. Kesalahan "unknown option" berarti Builder menebak flag yang tidak dimiliki versi Anda. Suruh ia menjalankan apidog run --help dan salin flag yang tepat dari sana, yang selalu benar untuk versi terinstal Anda.
Ini melaporkan kelulusan pada eksekusi yang gagal. Yang paling mahal, dan alasan aturan kode keluar ada di project_rules.md Anda dan langkah verifikasi Anda. Ketika ringkasan dan kode keluar tidak sesuai, kode keluar yang benar.
Dari agen harian ke perulangan yang teruji
Itulah pengaturannya. Instal apidog-cli sekali mengikuti panduan instalasi, tambahkan blok Apidog singkat ke .trae/rules/project_rules.md, dan Builder tahu cara menjalankan tes API Anda dan membaca hasilnya di dalam perulangan yang sama yang sudah digunakannya untuk mengedit kode. Endpoint yang rusak tertangkap saat Builder masih mengerjakan perubahan, bukan setelah itu dirilis.
Sebuah pengujian di balik GUI berjalan ketika manusia mengklik; sebuah perintah satu baris berjalan kapan pun Builder memutuskan. Anda terus membangun skenario secara visual di Apidog, dan agen Anda menjalankannya di tempat yang tidak Anda perhatikan. Unduh Apidog, bangun satu skenario, masukkan perintah apidog run-nya ke .trae/rules/project_rules.md, dan saksikan Builder mengambilnya pada perubahan berikutnya. Ketika Anda siap untuk menjalankan skenario yang sama tanpa kehadiran agen, Apidog CLI di GitHub Actions mencakup rahasia, reporter, dan gating kode keluar untuk CI.