Keploy memberikan sesuatu yang tidak dapat diberikan oleh sebagian besar alat pengujian: pembuatan pengujian tanpa usaha dari lalu lintas nyata. Anda mengarahkannya ke aplikasi yang sedang berjalan, ia memantau lapisan jaringan, dan mengembalikan kasus pengujian beserta _mock_ untuk dependensi Anda. Tanpa SDK, tanpa kode pengujian. Ini sangat berguna, dan ini juga alasan mengapa orang mulai mencari alternatif Keploy saat pengaturan mereka tidak sesuai dengan model tersebut.
Apa itu Keploy
Keploy adalah platform _open-source_ (Apache-2.0) untuk membuat _sandbox_ pengujian terisolasi untuk pengujian API, integrasi, dan _end-to-end_. Keploy memiliki dua alur kerja.
Yang pertama adalah rekam dan putar ulang. Keploy menangkap interaksi API nyata dan dependensinya (kueri basis data, panggilan jaringan, peristiwa _streaming_) pada lapisan jaringan menggunakan eBPF. Kemudian memutarnya ulang secara deterministik di mesin Anda atau di CI. Dari lalu lintas yang ditangkap tersebut, ia secara otomatis menghasilkan kasus pengujian dan _mock_/_stub_ untuk setiap dependensi yang disentuh oleh permintaan. Karena penangkapan terjadi pada lapisan eBPF, ini tanpa kode dan agnostik-bahasa. Anda tidak perlu mengubah apa pun di aplikasi Anda.
Perintahnya singkat:
curl --silent -O -L https://keploy.io/install.sh && source install.sh
keploy record -c "CMD_TO_RUN_APP"
keploy test -c "CMD_TO_RUN_APP" --delay 10
Alur kerja kedua adalah pembuatan pengujian AI. Keploy dapat membangun _suite_ pengujian API tervalidasi dari spesifikasi OpenAPI, koleksi Postman, perintah cURL, atau _endpoint_ langsung, dengan pembersihan otomatis dan _mocking_ dependensi.
Ini mencakup berbagai _stack_: Go, Java, Node.js, Python, Rust, C#, C/C++, dan TypeScript; gRPC, GraphQL, HTTP/REST, Kafka, dan RabbitMQ; PostgreSQL, MySQL, MongoDB, dan Redis. Gambaran lengkapnya ada di dokumen Keploy dan repositori GitHub Keploy.
Mengapa tim mencari alternatif Keploy
Keploy kuat, tetapi modelnya memiliki kekurangan.
- eBPF bergantung pada Linux dan _privilege_ tinggi. Penangkapan lapisan jaringan membutuhkan _kernel_ Linux dan izin untuk melampirkan _probe_. Itu tidak masalah pada _runner_ CI Linux. Akan lebih banyak hambatan pada laptop yang terkunci atau kotak dev Windows/macOS.
- Pengujian yang direkam memerlukan kurasi. Pengujian yang dihasilkan dari lalu lintas nyata membawa apa pun yang dibawa oleh lalu lintas tersebut: _timestamp_, token, ID sekali pakai, _noise_. Anda meninjau dan memangkasnya sebelum menjadi _suite_ yang stabil.
- Ini adalah pembuatan pengujian, bukan platform lengkap. Keploy membuat dan memutar ulang pengujian. Ini bukan tempat Anda mendesain API, menulis dokumentasi, menjalankan _mock server_ untuk tim _front-end_, atau berkolaborasi dalam kontrak API bersama.
- Beberapa tim menginginkan _suite_ yang ditulis sendiri. Pengujian yang ditangkap menjelaskan apa yang terjadi. Mereka tidak menjelaskan apa yang seharusnya terjadi. Jika Anda menginginkan _assertion_ yang Anda tulis dengan sengaja, dikontrol versinya, dan dapat dibaca setahun kemudian, pengujian yang direkam adalah titik awal, bukan tujuan.
Semua ini tidak membuat Keploy salah. Ini memberi tahu Anda apa yang harus dicari sebagai pengganti. Jadi, berikut adalah alternatifnya, dengan pro dan kontra yang jujur.
1. Apidog CLI (terbaik untuk _suite_ yang ditulis sendiri dan mudah dipelihara di dalam platform lengkap)
Apidog adalah platform API _all-in-one_ yang mencakup desain, _debugging_, _mocking_, dokumentasi, dan pengujian. Apidog CLI (apidog run) menjalankan skenario pengujian dan koleksi yang Anda tulis di aplikasi, dari terminal atau CI/CD Anda.
Di mana Keploy menangkap perilaku, Apidog meminta Anda untuk mendesainnya. Anda membangun skenario sekali, menambahkan _assertion_ yang Anda kontrol, dan menjalankannya di mana saja. CLI melakukan pengujian berbasis data dengan -d (CSV atau JSON), beralih lingkungan dengan -e, mengeluarkan laporan dalam format CLI, HTML, dan JSON, dan mendorong laporan _cloud_ dengan --upload-report. Ini dapat mengimpor OpenAPI dan mengelola _endpoint_, skema, cabang, dan permintaan _merge_ sebagai kode. Apidog juga memiliki pembuatan kasus pengujian AI dari skema dan _endpoint_ API Anda, yang ditulis di dalam aplikasi, yang merupakan titik tumpang tindih dengan pembuatan berbasis spesifikasi Keploy.
Berikut adalah garis jujur, karena kedua alat ini berada dalam kategori yang berbeda. Apidog tidak menangkap lalu lintas langsung melalui eBPF, dan tidak secara otomatis menghasilkan pengujian dengan merekam panggilan produksi ditambah _mock_ basis data. Kemampuan rekam-dan-putar-ulang dari lalu lintas nyata adalah kekuatan khas Keploy. Jika penangkapan perilaku _runtime_ tanpa kode adalah seluruh pekerjaan, Apidog bukanlah penggantinya. Jika Anda menginginkan _suite_ pengujian yang dapat dipelihara ditambah desain, _mocking_, dan dokumen di satu tempat, di situlah Apidog cocok.
Mulailah dengan panduan lengkap Apidog CLI, kemudian panduan instalasi. Untuk alur kerja yang lebih mendalam, ada pengujian berbasis data, laporan pengujian, _pipeline_ CI/CD, dan GitHub Actions. Aspek AI tercakup dalam pembuatan kasus pengujian bertenaga AI dan pembuatan skrip pengujian dari OpenAPI. Jika Anda mempertimbangkan keduanya secara langsung, lihat Apidog CLI vs Keploy dan panduan migrasi.
Kelebihan: Pengujian yang ditulis sendiri, mudah dibaca, ramah versi. Siklus hidup penuh (desain, _mock_, dokumen, pengujian). Eksekusi berbasis data, berbagai format laporan, siap CI. Pembuatan pengujian AI dari spesifikasi Anda. Kekurangan: Tidak ada penangkapan lalu lintas eBPF dan tidak ada _auto-mock_ dari lalu lintas nyata. Anda menulis skenario daripada merekamnya. Tidak ada _linter_ OpenAPI _standalone_ di CLI.
2. Postman / Newman
Postman adalah klien API yang paling dikenal luas, dan Newman adalah _runner_ CLI-nya. Anda membangun permintaan dan skrip pengujian di Postman, lalu menjalankan koleksi tanpa antarmuka (_headless_) dengan Newman di CI.
Ini adalah rekan terdekat dengan model _suite_ yang ditulis sendiri. Jika tim Anda sudah menggunakan Postman, Newman adalah jalur paling mudah untuk menjalankan perintah baris dan _pipeline_.
Kelebihan: Ekosistem besar, UI yang familiar, format koleksi yang matang, komunitas yang kuat. Kekurangan: Pengujian adalah cuplikan JavaScript yang terpasang pada permintaan, yang meluas seiring bertambahnya _suite_. Eksekusi berbasis data dan pelaporan lebih manual daripada di CLI yang dibuat khusus. Seperti Apidog, ia tidak merekam perilaku _runtime_ nyata seperti yang dilakukan Keploy. Lihat perbandingan berdampingan di Apidog CLI vs Newman.
3. Hoppscotch CLI
Hoppscotch adalah klien API _open-source_ yang ringan, dan CLI-nya menjalankan koleksi Anda yang tersimpan dari terminal. Ini sangat cocok untuk tim kecil dan proyek _open-source_ yang menginginkan sesuatu yang cepat dan gratis tanpa instalasi yang berat.
Kelebihan: _Open source_, ringan, cepat dipelajari, baik untuk menjalankan koleksi sederhana. Kekurangan: Lebih tipis dalam fitur pengujian, pelaporan, dan siklus hidup tingkat lanjut daripada platform yang lebih besar. Seperti alat pengujian yang ditulis sendiri lainnya, tidak ada penangkapan lalu lintas atau _mocking_ dependensi dari eksekusi nyata. Dibandingkan dalam Apidog CLI vs Hoppscotch CLI.
4. Schemathesis (fuzzing berbasis properti)
Schemathesis adalah jenis yang berbeda, dan itulah intinya. Alih-alih menjalankan pengujian yang Anda tulis, ia membaca skema OpenAPI atau GraphQL Anda dan menghasilkan banyak masukan untuk mencari _crash_, pelanggaran skema, dan perilaku yang tidak terdefinisi. Ini adalah _fuzzing_ berbasis properti, bukan pengujian berbasis contoh.
Ini menjawab pertanyaan yang tidak dijawab dengan baik oleh Keploy maupun alat _suite_ yang ditulis sendiri: apakah API saya bertahan terhadap masukan yang tidak pernah saya pikirkan untuk dicoba? Banyak tim menjalankan Schemathesis bersamaan dengan _suite_ utama mereka daripada sebagai penggantinya.
Kelebihan: Menemukan _edge case_ yang terlewat oleh manusia. Berbasis skema, sehingga skalanya sesuai dengan spesifikasi Anda. Kuat untuk pengerasan dan kesesuaian kontrak. Kekurangan: _Fuzzing_ memunculkan _noise_ yang perlu Anda saring. Ini memvalidasi terhadap skema, sehingga respons yang salah tetapi valid dapat lolos. Ini adalah pelengkap, bukan strategi pengujian penuh. Untuk penempatan ini, lihat alat pengujian kontrak dan _mocking_ serta rangkuman alat otomasi pengujian API yang lebih luas.
5. Rekam-putar-ulang dan _mocking_ gaya VCR / Mountebank
Ini adalah kategori yang paling dekat dengan Keploy secara semangat. Alat VCR berbasis _library_ (VCR untuk Ruby, vcrpy untuk Python, dan sejenisnya) merekam interaksi HTTP ke dalam file “kaset” dan memutarnya ulang dalam pengujian. Mountebank adalah alat _standalone_ yang merekam dan membuat _stub_ dependensi layanan melalui jaringan.
Jika daya tarik Keploy adalah “menangkap panggilan nyata dan memutarnya kembali,” ini memberikan Anda sebagian dari itu tanpa eBPF. Perbedaannya penting: VCR merekam pada lapisan klien HTTP di dalam kode Anda (Anda menambahkan _library_), dan Mountebank berfungsi sebagai _proxy_. Keduanya tidak menangkap kueri basis data atau perilaku dependensi tingkat _kernel_ seperti yang dilakukan penangkapan eBPF Keploy. Mereka merekam HTTP tingkat aplikasi, bukan gambaran _runtime_ lengkap.
Kelebihan: Rekam-putar-ulang sejati untuk HTTP tanpa persyaratan Linux/eBPF. Opsi spesifik bahasa yang matang dan dipahami dengan baik tersedia. Kekurangan: Integrasi tingkat kode (VCR) atau _proxy_ yang Anda operasikan (Mountebank). Hanya lapisan HTTP, jadi tidak ada penangkapan basis data atau dependensi _streaming_. Lebih banyak pengaturan daripada _probe_ Keploy yang tanpa kode. Lihat skema OpenAPI dan pembuatan data _mock_ untuk sisi _mocking_.
Tabel perbandingan
| Alat | Pendekatan | Otomatis menangkap lalu lintas nyata | _Mock_ DB/dependensi dari lalu lintas | Platform API lengkap | Lisensi |
|---|---|---|---|---|---|
| Keploy | eBPF rekam-putar-ulang + pembuatan pengujian AI | Ya (eBPF, tanpa kode) | Ya | Tidak (pembuatan pengujian) | Apache-2.0 |
| Apidog CLI | Skenario yang ditulis sendiri + pembuatan pengujian AI dari spesifikasi | Tidak | Tidak | Ya | Komersial (tingkat gratis) |
| Postman / Newman | Koleksi yang ditulis sendiri + pengujian JS | Tidak | Tidak | Sebagian | Komersial (tingkat gratis) |
| Hoppscotch CLI | Koleksi yang ditulis sendiri | Tidak | Tidak | Sebagian | _Open source_ |
| Schemathesis | _Fuzzing_ berbasis properti dari skema | Tidak | Tidak | Tidak | _Open source_ |
| VCR / Mountebank | Rekam-putar-ulang HTTP + _stubbing_ | Hanya HTTP | Hanya HTTP | Tidak | _Open source_ |
Cara memilih
Sesuaikan alat dengan kebutuhan, bukan dengan _hype_.
- Anda menginginkan penangkapan perilaku _runtime_ nyata tanpa kode, termasuk _mock_ basis data, dan Anda berjalan di Linux. Keploy adalah alat yang tepat. Tidak ada alternatif yang mereplikasi penangkapan eBPF di seluruh dependensi DB dan _streaming_. Jujurlah pada diri sendiri di sini: jika itu adalah persyaratannya, jangan beralih.
- Anda menginginkan versi parsial dari rekam-putar-ulang tanpa eBPF, pada lapisan HTTP. _Library_ gaya VCR atau Mountebank akan membantu Anda mencapainya dengan sedikit pengaturan.
- Anda menginginkan pengujian yang Anda tulis sendiri, baca, dan pelihara, ditambah desain, _mocking_, dan dokumen di satu tempat. Apidog CLI adalah pilihan terkuat, dan ia menambahkan pembuatan pengujian AI dari spesifikasi Anda. Postman/Newman dan Hoppscotch CLI adalah pilihan pengujian yang ditulis sendiri yang lebih ringan.
- Anda ingin memperkuat API terhadap masukan yang tidak pernah direncanakan siapa pun. Tambahkan Schemathesis di atas apa pun yang Anda jalankan.
Bagi sebagian besar tim, jawaban sebenarnya adalah dua alat, bukan satu. Tangkap atau _fuzz_ untuk menemukan apa yang rusak, lalu tulis _suite_ yang dapat dipelihara untuk mengunci perilaku tersebut. Itulah alur kerja yang dibangun oleh Apidog, dan Anda dapat mengunduh Apidog dan menjalankan skenario yang ditulis sendiri dari CLI dalam beberapa menit. Jika Keploy adalah titik awal Anda, uraian alternatif Keploy terbaik dan apa itu Keploy memberikan Anda latar belakang lengkap.