Jika tim Anda memulai dengan Keploy, Anda mungkin menyukai satu hal tentangnya: Anda menjalankan aplikasi Anda, mengakses beberapa endpoint, dan tes muncul. Tanpa menulis pernyataan, tanpa meng-stub dependensi secara manual. Keploy menangkap lalu lintas nyata di lapisan jaringan dan memutarnya kembali untuk Anda.
Jadi mengapa ada orang yang ingin beralih dari Keploy? Biasanya karena kebutuhan yang berbeda. Tes yang ditangkap sangat bagus untuk menangkap regresi dari apa yang sudah terjadi, tetapi lebih sulit dibaca, ditinjau, dan dimiliki bersama oleh tim. Pada titik tertentu Anda menginginkan tes yang dapat dibuka oleh insinyur baru dalam permintaan tarik, dipahami sekilas, dan diubah dengan sengaja. Anda menginginkan data tes yang Anda kontrol, lingkungan yang dapat Anda alihkan dengan sebuah tanda, dan server mock yang Anda rancang daripada yang berasal dari rekaman.
Dua Paradigma Berbeda, Dibandingkan Secara Jujur
Keploy dan Apidog tumpang tindih dalam kata "pengujian API," tetapi mereka adalah kategori alat yang berbeda. Berpura-pura sebaliknya hanya akan merugikan Anda.
Keploy adalah platform open-source untuk membuat kotak pasir pengujian terisolasi. Fitur utamanya adalah rekam dan putar ulang: menggunakan eBPF di lapisan jaringan, ia menangkap panggilan API nyata dan dependensinya (kueri basis data, layanan hilir, peristiwa streaming) tanpa SDK dan tanpa perubahan kode. Dari lalu lintas yang ditangkap tersebut, ia secara otomatis menghasilkan kasus uji dan mock untuk dependensi tersebut. Ia juga memiliki jalur pembuatan tes AI yang membangun suite dari spesifikasi OpenAPI, koleksi Postman, perintah cURL, atau endpoint langsung. Karena penangkapan terjadi di lapisan eBPF, ia bersifat agnostik bahasa dan mengandalkan Linux serta hak istimewa yang ditingkatkan. Anda dapat membaca kode sumbernya di GitHub.
Apidog adalah platform API all-in-one: desain, debug, mock, dokumen, dan tes di satu tempat. Apidog CLI (apidog run) menjalankan skenario tes dan koleksi yang Anda buat, dari terminal Anda dan di CI/CD. Ini mendukung pengujian berbasis data, pengalihan lingkungan, berbagai format laporan, dan laporan cloud. Apidog juga memiliki pembuatan kasus uji AI, tetapi ia bekerja dari skema API dan endpoint Anda di dalam aplikasi, bukan dengan merekam lalu lintas produksi.
Berikut adalah garis jujur yang Anda butuhkan sebelum merencanakan apa pun: Apidog tidak menangkap lalu lintas langsung melalui eBPF, dan tidak secara otomatis menghasilkan tes dengan merekam panggilan produksi ditambah mock dependensi. Itulah kekuatan khas Keploy. Jika penangkapan saat runtime adalah inti dari alur kerja Anda, pertahankan Keploy untuk pekerjaan itu. Yang Anda dapatkan dengan beralih ke Apidog adalah tes yang dirancang, dapat ditinjau, dan lintas tim serta platform yang mencakup seluruh siklus hidup API.
| Pendekatan Keploy | Pendekatan Apidog |
|---|---|
keploy record menangkap lalu lintas nyata melalui eBPF |
Impor permukaan API Anda sebagai OpenAPI, Postman, atau cURL |
| Tes secara otomatis dihasilkan dari panggilan yang ditangkap | Pembuatan kasus uji AI dari spesifikasi, ditambah skenario yang Anda buat |
keploy test --delay 10 memutar ulang rekaman |
apidog run menjalankan skenario yang dibuat di CI |
| Mock dependensi ditangkap dari lalu lintas DB/jaringan nyata | Server mock yang Anda desain dan kontrol |
| Data tes yang telah ada dalam rekaman | Pengujian berbasis data melalui -d (CSV/JSON) yang Anda kelola |
| Lingkungan implisit dari proses yang direkam | Lingkungan eksplisit yang diaktifkan dengan -e |
| Linux/eBPF, hak istimewa yang ditingkatkan | Berjalan di mana saja CLI berjalan, termasuk runner CI standar |
Bacalah tabel itu sebagai panduan terjemahan, bukan kartu skor fitur. Setiap kemampuan Keploy dipetakan ke langkah penulisan yang disengaja di Apidog. Anda menukar "alat tersebut mengetahuinya dari lalu lintas" dengan "Anda menjelaskan apa yang benar itu seperti apa."
Langkah 1: Tangkap Permukaan API Anda sebagai Spesifikasi
Keploy dimulai dari aplikasi yang sedang berjalan. Apidog dimulai dari deskripsi API Anda. Jadi tugas pertama adalah mendapatkan deskripsi tersebut.
Jika Anda sudah menerbitkan dokumen OpenAPI, Anda selesai. Tunjuk ke sana dan lanjutkan. Jika tidak, Anda memiliki beberapa opsi, yang semuanya menghasilkan sesuatu yang dapat diimpor:
- Hasilkan OpenAPI dari framework Anda (kebanyakan framework modern memiliki eksportir atau pustaka yang mengeluarkannya).
- Ekspor koleksi Postman jika tim Anda sudah memilikinya.
- Kumpulkan perintah cURL yang Anda gunakan untuk mengakses setiap endpoint.
Efek samping yang bagus: jika Anda memiliki rekaman Keploy, permintaan yang ditangkap adalah inventaris dunia nyata dari endpoint mana yang benar-benar dipanggil dan dengan payload apa. Gunakan rekaman tersebut sebagai daftar periksa agar spesifikasi Anda mencakup area permukaan yang sama, meskipun Anda tidak akan mengimpor rekaman itu sendiri.
Langkah 2: Impor ke Apidog
Unduh Apidog, buat proyek, dan impor file OpenAPI, koleksi Postman, atau perintah cURL Anda. Apidog membaca spesifikasi dan mengisi endpoint, skema permintaan, parameter, dan model respons. Anda sekarang memiliki definisi terstruktur dari setiap endpoint, permukaan yang sama dengan yang diakses Keploy, tetapi dalam bentuk yang dapat Anda edit, versikan, dan bagikan.
Ini juga saat perbedaan platform muncul. Endpoint yang diimpor tersebut bukan hanya alat uji. Endpoint tersebut adalah dokumentasi langsung, permintaan yang dapat di-debug, dan dasar untuk server mock, semuanya dari satu impor. Untuk panduan langkah demi langkah tentang toolchain, panduan lengkap Apidog CLI mencakup pengaturan lengkapnya.
Langkah 3: Hasilkan Suite Tes Awal, Lalu Buat Skenario Nyata
Di sinilah Anda mendapatkan kembali sebagian kecepatan yang Anda sukai dari Keploy. Pembuatan kasus uji AI Apidog membaca skema dan endpoint yang Anda impor dan menyusun kasus uji untuk Anda: permintaan yang valid, nilai batas, dan respons kegagalan umum berdasarkan spesifikasi. Ini adalah titik awal yang kuat, dan membantu Anda memulai dengan cepat dari halaman kosong. Jika Anda ingin melihat bagaimana ini dibandingkan di berbagai alat, rangkuman generator kasus uji AI terbaik menempatkannya dalam konteks.
Dua catatan jujur. Pertama, kasus yang disusun AI (di Apidog atau Keploy) membutuhkan tinjauan manusia. Perlakukan output sebagai draf, buang apa yang tidak berlaku, dan perketat pernyataan. Kedua, ini adalah generasi dari spesifikasi, bukan dari perilaku runtime, jadi ia tidak akan tahu tentang kekhasan yang hanya muncul di bawah data produksi nyata. Itulah celah yang diisi oleh penangkapan Keploy, dan itu adalah celah yang Anda terima ketika Anda beralih ke tes yang dirancang.
Kemudian Anda membuat skenario yang penting. Sebuah skenario merangkai permintaan menjadi alur nyata: membuat pengguna, masuk dengan token yang dikembalikan, mengambil profil, memperbaruinya, menghapusnya. Anda menegaskan kode status, bidang respons, dan bagaimana data mengalir dari satu langkah ke langkah berikutnya. Ini adalah pekerjaan yang dilakukan Keploy secara implisit dalam sebuah rekaman. Melakukannya secara eksplisit membutuhkan lebih banyak upaya di awal, dan itu akan terbayar setiap kali seseorang membaca, meninjau, atau mengubah tes nanti. Panduan tentang cara menulis kasus uji dengan bantuan AI membantu Anda menyeimbangkan generasi dengan penulisan manual.
Langkah 4: Atur Lingkungan dan Masukan Berbasis Data
Sebuah rekaman membawa satu set nilai dari satu eksekusi. Tes yang dibuat harus berjalan di lingkungan mana pun dengan kumpulan data apa pun.
Definisikan lingkungan di Apidog (lokal, staging, produksi) dengan URL dasar, token, dan variabelnya sendiri. Saat runtime, Anda memilih satu dengan -e. Untuk data pengujian, lampirkan file CSV atau JSON dan Apidog menjalankan setiap skenario sekali per baris, sehingga satu skenario login mencakup selusin kombinasi kredensial. Anda menunjuk ke file dengan -d. Panduan pengujian berbasis data menunjukkan format file dan pengikatan variabel secara detail.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Ini adalah peningkatan konkret dibandingkan rekaman tetap. Data pengujian Anda adalah file yang Anda miliki, tinjau dalam permintaan tarik, dan perluas saat kasus-kasus khusus baru muncul.
Langkah 5: Jalankan di CI dengan apidog run
Perintah yang menggantikan keploy test dalam pipeline Anda adalah apidog run. Perintah ini menjalankan skenario yang Anda buat, menerapkan lingkungan dan file data yang dipilih, dan mengeluarkan laporan. Anda dapat menghasilkan output CLI, HTML, dan JSON, serta mengunggah hasilnya ke cloud dengan --upload-report untuk tautan yang dapat dibagikan.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Menghubungkan ini ke pipeline Anda memiliki bentuk yang sama dengan langkah pengujian CI lainnya: instal CLI, berikan token dan ID skenario Anda, gagalkan build jika keluar dengan nilai bukan nol. Panduan pipeline CI/CD dan panduan GitHub Actions mencakup YAML yang tepat, dan panduan laporan pengujian menjelaskan cara membaca output yang sebenarnya akan dilihat oleh tim Anda.
Langkah 6: Bangun Server Mock yang Anda Kendalikan
Keploy memberi Anda mock secara gratis dengan menangkap lalu lintas dependensi selama perekaman. Apidog mengambil jalur lain: Anda mendesain mock-nya. Karena Anda sudah mengimpor skema Anda, Apidog dapat menghasilkan server mock darinya, mengembalikan respons contoh yang realistis berdasarkan jenis bidang dan aturan yang Anda tetapkan. Anda memutuskan latensi, kasus kesalahan, dan payload yang tepat.
Perdagangannya sama seperti di tempat lain dalam panduan ini. Mock yang ditangkap mencerminkan apa yang sebenarnya dilakukan dependensi Anda; mock yang dirancang mencerminkan apa yang Anda putuskan harus mereka lakukan. Untuk pengujian kontrak dan CI yang stabil, mock yang dirancang cenderung menang karena tidak berubah dengan produksi. Jika Anda ingin latar belakang yang lebih dalam, lihat alat pengujian kontrak dan mocking serta pembuatan data mock dari skema OpenAPI.
Apa yang Anda Pertahankan dan Apa yang Anda Korbankan
Jujurlah dengan tim Anda tentang kedua sisi perpindahan ini.
Anda kehilangan penangkapan otomatis. Tidak ada keploy record yang mengamati lalu lintas nyata, tidak ada mock dependensi yang berasal dari eksekusi produksi, tidak ada keajaiban eBPF yang tidak memerlukan kode. Jika kemampuan tersebut sangat penting bagi Anda, pertahankan Keploy di kotak peralatan untuk itu. Kedua alat dapat hidup berdampingan.
Anda mendapatkan tes yang terbaca seperti dokumentasi, lingkungan yang dapat Anda alihkan dengan tanda, data tes yang Anda miliki dan tinjau, server mock yang Anda rancang, dan satu platform untuk desain, debugging, dokumen, dan pengujian. Biayanya nyata (penulisan membutuhkan lebih banyak usaha daripada merekam), dan hasilnya adalah pemeliharaan yang dapat ditindaklanjuti oleh seluruh tim Anda. Survei yang lebih luas tentang alat otomatisasi pengujian API menempatkan pertukaran ini dalam konteks, dan cara menguji API dengan Apidog adalah bacaan lanjutan yang bagus dan praktis.
Jika Anda sedang mempertimbangkan kedua alat tersebut secara berdampingan, perbandingan Apidog vs Keploy menguraikannya fitur demi fitur, dan jika Keploy secara khusus tidak cocok untuk tim Anda, rangkuman alternatif Keploy terbaik layak untuk dilihat.
FAQ
Bisakah Apidog mengimpor rekaman Keploy saya yang sudah ada? Tidak secara langsung. Rekaman Keploy adalah tangkapan runtime, dan Apidog bekerja dari spesifikasi API. Jalur praktisnya adalah menangkap permukaan API Anda sebagai OpenAPI (atau Postman/cURL) dan mengimpornya. Gunakan rekaman Keploy Anda sebagai daftar periksa endpoint mana yang akan dicakup.
Apakah Apidog merekam lalu lintas langsung dan secara otomatis mem-mock basis data saya seperti Keploy? Tidak. Apidog tidak menangkap lalu lintas melalui eBPF dan tidak secara otomatis menghasilkan mock dependensi dari eksekusi nyata. Itu adalah kekuatan khas Keploy. Apidog menghasilkan tes dan mock dari skema Anda, dan Anda membuat skenario di atas itu.
Apa yang menggantikan keploy record dan keploy test? Tidak ada yang setara dengan record. Sebagai gantinya, Anda mengimpor spesifikasi, menghasilkan suite awal dengan AI, membuat skenario, dan menjalankannya dengan apidog run sebagai pengganti keploy test.
Apakah sepadan dengan upaya penulisan tambahan untuk bermigrasi dari Keploy? Jika Anda menginginkan tes yang mudah dibaca, dapat ditinjau dalam permintaan tarik, dan dimiliki bersama oleh tim, ya. Jika kebutuhan inti Anda adalah penangkapan perilaku runtime nyata tanpa usaha termasuk mock dependensi, Keploy masih melakukannya lebih baik, jadi pertahankan untuk pekerjaan itu.
Bisakah saya menjalankan kedua alat sekaligus? Ya. Banyak tim menggunakan Keploy untuk pemeriksaan regresi berbasis penangkapan dan Apidog untuk suite end-to-end yang dirancang, dokumen, dan mock. Keduanya memecahkan masalah yang berbeda.
Tempat Memulai
Pilih satu layanan. Ekspor spesifikasi OpenAPI-nya, impor ke Apidog, biarkan AI menyusun beberapa kasus uji, lalu buat satu skenario nyata dengan lingkungan dan file data kecil. Jalankan dengan apidog run dan sambungkan ke CI. Setelah alur itu terasa baik, perluas. Anda akan menukar kenyamanan perekaman dengan tes yang dapat dibaca, diubah, dan dipercaya oleh seluruh tim Anda. Untuk mempelajari lebih dalam tentang CLI itu sendiri, mulailah dengan panduan instalasi dan panduan pengujian REST API baris perintah.