Kode Anda bergantung pada layanan yang tidak Anda kendalikan. Gerbang pembayaran, API mitra, mainframe lama, layanan mikro tim lain. Dependensi tersebut sedang dalam pemeliharaan, membatasi laju eksekusi pengujian Anda, mengenakan biaya per panggilan, atau mengembalikan data yang tidak konsisten. Jadi pengembangan Anda terhenti dan CI pipeline Anda menjadi merah karena alasan yang tidak ada hubungannya dengan kode Anda.
Virtualisasi layanan memperbaiki masalah ini. Anda mengganti dependensi yang sebenarnya dengan pengganti yang berperilaku sama, sehingga Anda dapat membangun dan menguji terhadap sesuatu yang sepenuhnya Anda kendalikan. Panduan ini menjelaskan apa itu virtualisasi layanan, perbedaannya dengan mocking dan stubbing, mengapa tim menggunakannya, dan alat apa yang dapat melakukannya, dengan perintah nyata untuk WireMock, Hoverfly, Mountebank, opsi perusahaan, dan server mock Apidog untuk virtualisasi kontrak API.
Apa itu virtualisasi layanan
Virtualisasi layanan mensimulasikan perilaku dependensi yang tidak Anda kendalikan sehingga aplikasi Anda dapat berkomunikasi dengan simulasi daripada dengan sistem yang sebenarnya.
Kata "perilaku" sangat penting di sini. Layanan virtual yang baik tidak hanya mengembalikan payload tetap. Layanan ini mencocokkan detail permintaan, mengembalikan respons yang berbeda untuk input yang berbeda, mempertahankan status di seluruh panggilan, menyuntikkan latensi dan kesalahan, dan berbicara protokol yang sama dengan sistem yang sebenarnya. Tujuannya adalah pengganti yang cukup realistis sehingga kode Anda tidak dapat membedakannya selama pengembangan dan pengujian.
Istilah "virtualisasi API" memiliki arti yang sama ketika dependensi adalah API HTTP, dan "simulator API" adalah alat yang menghasilkan endpoint virtual. Perlakukan keduanya sebagai sinonim untuk bagian virtualisasi layanan yang berfokus pada API.
Virtualisasi layanan vs mocking vs stubbing
Ketiga istilah ini tumpang tindih, dan orang menggunakannya secara longgar. Berikut adalah cara praktis untuk memisahkannya.
Sebuah stub mengembalikan respons yang sudah ditentukan sebelumnya. Ini mengabaikan permintaan dan selalu menjawab dengan cara yang sama. Jika pengujian Anda memanggil GET /user/42 dan stub diatur untuk mengembalikan objek pengguna tetap, ia akan mengembalikan objek yang sama tidak peduli ID apa yang Anda kirim. Stub adalah bentuk paling sederhana dan berada di dalam kode pengujian Anda.
Sebuah mock adalah stub yang juga memverifikasi interaksi. Ini mencatat bagaimana ia dipanggil (metode apa, argumen apa, berapa kali) sehingga pengujian Anda dapat menegaskan bahwa kode Anda menggunakan dependensi dengan benar. Mock adalah alat pengujian unit. Mereka biasanya berjalan dalam proses, dalam bahasa yang sama dengan kode Anda. Penjelasan kami tentang stubbing API vs mocking API membahas lebih dalam tentang pembagian ini.
Virtualisasi layanan beroperasi melalui jaringan, bukan di kode Anda. Ini membuat layanan yang berjalan pada port jaringan nyata yang berbicara protokol nyata. Aplikasi Anda terhubung ke sana dengan cara yang sama seperti terhubung ke produksi, dengan mengubah URL dasar atau pengaturan proxy. Layanan virtual dapat berstatus, dapat mencocokkan kondisi permintaan yang kompleks, dan dapat mensimulasikan perilaku tingkat protokol seperti kode status HTTP, header, streaming, dan kesalahan koneksi.
Garis antara "mock" dan "virtualisasi layanan" kabur dalam percakapan sehari-hari. Banyak tim menyebut server mock HTTP yang berjalan "mock" meskipun melakukan virtualisasi penuh. Itu tidak masalah. Perbedaan yang penting: apakah Anda mengganti objek di dalam proses Anda (mocking/stubbing), atau membuat layanan jaringan yang terhubung dengan aplikasi Anda (virtualisasi)? Lihat mocking API: semua yang perlu Anda ketahui untuk sisi mock.
Mengapa tim menggunakan virtualisasi layanan
Tiga masalah mendorong sebagian besar adopsi.
Dependensi belum siap. Tim frontend dan backend bekerja secara paralel, dan frontend membutuhkan API yang berfungsi sebelum backend menyediakannya. Layanan virtual yang dibangun dari kontrak API memungkinkan frontend membangun berdasarkan respons yang realistis hari ini. Tidak ada yang menunggu.
Dependensi mahal atau dibatasi laju. API pihak ketiga sering mengenakan biaya per panggilan atau membatasi laju secara agresif, sehingga menjalankan suite pengujian lengkap terhadap sandbox langsung menghabiskan kuota dan uang. Layanan virtual gratis untuk diakses, sehingga CI Anda dapat menjalankan ribuan skenario per hari.
Dependensi tidak konsisten atau sulit dikendalikan. Anda tidak dapat dengan mudah membuat penyedia pembayaran nyata mengembalikan kesalahan tertentu, batas waktu, atau mengirim respons yang salah format. Layanan virtual menghasilkan salah satu dari itu sesuai permintaan, begitulah cara Anda menguji jalur kesalahan yang rusak dalam produksi.
Ada juga manfaat kontrol. Dependensi nyata memiliki data yang berubah di bawah Anda. Layanan virtual memberi Anda status tetap dan diketahui, sehingga pengujian Anda deterministik. Build yang hijau berarti kode Anda berfungsi, bukan bahwa sistem jarak jauh kebetulan berperilaku hari ini.
Bagaimana virtualisasi layanan bekerja
Sebagian besar alat mengikuti salah satu dari dua pola.
Rekam dan putar ulang. Anda mengarahkan alat ke layanan nyata sebagai proxy, menjalankan lalu lintas nyata melaluinya sekali, dan alat itu menangkap pasangan permintaan/respons. Nantinya ia memutar ulang rekaman tersebut alih-alih memanggil layanan nyata. Ini cepat karena Anda tidak menulis respons secara manual. Mode tangkapan Hoverfly dan mode rekam WireMock keduanya bekerja dengan cara ini.
Didorong oleh spesifikasi. Anda mendefinisikan layanan virtual dari kontrak API atau secara manual: mendeklarasikan permintaan mana yang cocok dengan respons mana, menambahkan nilai dinamis, dan menyiapkan perilaku berstatus. Ini lebih banyak pekerjaan di awal tetapi memberi Anda kontrol penuh dan berfungsi bahkan ketika layanan nyata belum ada.
Bagaimanapun, mekanik intinya adalah pencocokan permintaan. Ketika sebuah permintaan tiba, alat akan memeriksanya terhadap serangkaian aturan (jalur, metode, parameter kueri, header, body) dan mengembalikan respons yang terikat pada kecocokan pertama. Alat yang lebih baik menambahkan templating, sehingga respons dapat mengulang kembali bagian dari permintaan atau menghasilkan nilai baru pada setiap panggilan. Begitulah cara layanan virtual terasa hidup daripada statis.
Alat-alat
Berikut adalah opsi utama, mulai dari alat berfokus HTTP open-source hingga suite perusahaan berat. Verifikasi versi dan fitur saat ini terhadap dokumen proyek masing-masing sebelum Anda berkomitmen, karena ini bergerak cepat.
WireMock
WireMock adalah API mocking open-source dan virtualisasi layanan untuk HTTP. Ini berjalan sebagai proses mandiri, tertanam dalam pengujian JVM, atau dalam container. Anda mendefinisikan pemetaan stub sebagai JSON, dan WireMock mencocokkan permintaan masuk dengannya. Ini mendukung perekaman dan pemutaran ulang terhadap layanan nyata, templating respons, skenario berstatus, injeksi kesalahan, dan penundaan yang disimulasikan.
Jalankan JAR mandiri:
java -jar wiremock-standalone-3.13.2.jar --port 8080
Kemudian daftarkan stub melalui API adminnya:
curl -X POST http://localhost:8080/__admin/mappings \
-H "Content-Type: application/json" \
-d '{
"request": {
"method": "GET",
"url": "/user/42"
},
"response": {
"status": 200,
"headers": { "Content-Type": "application/json" },
"jsonBody": { "id": 42, "name": "Ada Lovelace" }
}
}'
WireMock paling kuat ketika dependensi Anda adalah HTTP dan Anda menginginkan kontrol yang terperinci dalam pengaturan JVM atau container. Ada versi komersial yang di-host (WireMock Cloud) jika Anda menginginkan opsi terkelola.
Hoverfly
Hoverfly adalah alat virtualisasi layanan open-source ringan yang ditulis dalam Go. Ini berfungsi sebagai proxy: Anda mengarahkan lalu lintas keluar aplikasi Anda melalui Hoverfly, dan ia merekam respons nyata atau memutar ulang respons yang disimulasikan. Ini berjalan dalam beberapa mode, termasuk tangkap, simulasikan, mata-mata, modifikasi, sintesis, dan bedakan.
Alur dasar tangkap-lalu-putar ulang menggunakan perintah hoverctlnya:
hoverctl start
hoverctl mode capture
curl --proxy http://localhost:8500 https://api.example.com/user/42
hoverctl export simulation.json
hoverctl mode simulate
API admin Hoverfly berjalan pada port 8888 dan proxynya pada 8500 secara default. Model proxy rekam-dan-putar ulang membuatnya cocok ketika Anda ingin memvirtualisasikan lalu lintas yang ada dengan cepat daripada menulis setiap respons secara manual. Ada juga Hoverfly Cloud yang di-host.
Mountebank
Mountebank adalah alat open-source yang dibangun di sekitar "imposters." Sebuah imposter adalah layanan virtual tunggal yang mendengarkan pada satu port dan berbicara satu protokol. Selain HTTP dan HTTPS, Mountebank juga menangani TCP dan SMTP, yang berguna ketika dependensi Anda bukan API REST biasa. Anda mengendalikannya sepenuhnya melalui control plane REST pada port 2525.
Instal dan mulai:
npm install -g mountebank
mb
Kemudian buat imposter dengan POST JSON ke control port:
curl -X POST http://localhost:2525/imposters \ -H "Content-Type: application/json" \ -d '{ "port": 4545, "protocol": "http", "stubs": [{ "predicates": [{ "equals": { "method": "GET", "path": "/user/42" } }], "responses": [{ "is": { "statusCode": 200, "body": "{\"id\":42,\"name\":\"Ada Lovelace\"}" } }] }] }'
Predikat memutuskan permintaan mana yang cocok; respons mendefinisikan apa yang dikembalikan. Jangkauan multi-protokol Mountebank adalah pembeda di antara opsi open-source.
Parasoft Virtualize dan Broadcom Service Virtualization
Untuk perusahaan besar, pemain besar adalah Parasoft Virtualize dan Broadcom Service Virtualization (bagian dari suite DevTest). Ini adalah platform komersial yang dibangun untuk tim yang perlu mensimulasikan banyak protokol dan format pesan di luar HTTP, menghubungkan layanan virtual ke sumber data nyata, dan mengelola virtualisasi di banyak lingkungan secara terpusat.
Parasoft Virtualize mengiklankan dukungan untuk berbagai protokol dan format pesan standar industri, ditambah layanan virtual berbasis data yang diumpankan dari sumber data eksternal. Penawaran Broadcom menargetkan skenario perusahaan serupa dengan lingkungan tervirtualisasi untuk pengembangan dan pengujian paralel. Keduanya membawa lisensi perusahaan dan biaya pengaturan, jadi mereka cocok ketika Anda memvirtualisasikan protokol lama (mainframe, MQ, pesan panjang tetap) dalam skala besar daripada beberapa endpoint REST. Jika dependensi Anda adalah API HTTP biasa, alat open-source di atas atau platform API dapat membantu Anda dengan biaya yang lebih rendah. Konfirmasikan daftar protokol dan harga saat ini dengan setiap vendor.
Apidog: virtualisasi layanan ringan untuk kontrak API
Jika dependensi yang perlu Anda virtualisasikan adalah API HTTP yang didefinisikan oleh kontrak, Apidog mencakup bagian itu tanpa alat terpisah. Saat Anda merancang atau mengimpor API, Apidog secara otomatis menyiapkan server mock untuknya. Frontend atau suite pengujian Anda mendapatkan endpoint yang berfungsi dari skema saja, sebelum kode backend ada.
Yang membuat ini lebih dekat ke virtualisasi daripada stub biasa adalah bahwa mock Apidog sadar skema dan dinamis. Smart Mock-nya membaca Skema JSON Anda dan menghasilkan respons yang menghormati setiap batasan (tipe, format, enum, bidang yang wajib diisi). Ini juga mencocokkan nama bidang dengan aturan bawaan, sehingga bidang bernama email mengembalikan email yang valid dan bidang bernama city mengembalikan nama kota, alih-alih sampah placeholder. Untuk kontrol yang lebih baik, nilai dinamis berdasarkan Faker.js menghasilkan data yang realistis di setiap panggilan, dan Anda dapat menyematkan nilai tetap di mana Anda membutuhkan determinisme.
Anda juga dapat menulis aturan mock kustom yang mengembalikan respons berbeda berdasarkan parameter permintaan, yang merupakan perilaku pencocokan permintaan yang memisahkan virtualisasi dari stub tetap. Server mock berjalan di GUI atau headless, sehingga cocok untuk pengembangan lokal dan CI. Lihat cara mem-mock API dalam satu menit untuk panduan.
Di mana Apidog cocok: virtualisasi layanan kontrak API untuk HTTP/REST dan sejenisnya. Di mana tidak cocok: ini bukan alat rekam-dan-putar ulang berbasis proxy untuk protokol lama arbitrer, dan ini bukan generator beban. Untuk itu, alat-alat di atas adalah pilihan yang tepat. Untuk perbandingan alat-ke-alat yang lebih luas, lihat perbandingan alat mocking API online dan 10 alat mocking API terbaik.
Cara memulai
Cocokkan alat dengan dependensi, bukan sebaliknya.
- Identifikasi protokolnya. HTTP/REST biasa? Hampir semua di sini berfungsi, dan platform API adalah yang paling minim gesekan. Membutuhkan TCP atau SMTP? Mountebank. Protokol perusahaan lama dalam skala besar? Parasoft atau Broadcom.
- Tentukan rekam vs spesifikasi. Jika layanan nyata ada dan Anda dapat mengarahkan lalu lintas melaluinya, rekam-dan-putar ulang (Hoverfly, mode rekam WireMock) adalah yang tercepat. Jika belum ada, jalankan layanan virtual dari kontrak API (Apidog, stub WireMock, imposter Mountebank).
- Arahkan aplikasi Anda ke sana. Ubah URL dasar atau pengaturan proxy di lingkungan pengujian atau pengembangan Anda, dan simpan di balik konfigurasi sehingga beralih antara virtual dan nyata adalah satu variabel.
- Tambahkan kasus kegagalan. Manfaatnya adalah menguji jalur kesalahan, jadi tambahkan respons untuk 4xx dan 5xx, batas waktu, dan body yang salah format. Itulah bagian yang tidak akan memungkinkan Anda untuk berlatih dengan dependensi nyata.
- Jalankan di CI. Layanan virtual yang hanya berjalan di laptop Anda membantu Anda tetapi tidak membantu build. Masukkan ke dalam pipeline sehingga hijau berarti hijau. Jika Anda membutuhkan mock yang berjalan headless di CI tanpa GUI, lihat alat mock API headless.
Untuk pertukaran antara dependensi virtual dan langsung secara umum, server mock vs server nyata menjelaskan kapan harus menggunakan masing-masing.
FAQ
Apakah virtualisasi layanan sama dengan mocking? Tidak persis. Mocking biasanya mengganti objek di dalam proses Anda untuk pengujian unit dan memverifikasi bagaimana ia dipanggil. Virtualisasi layanan menyiapkan layanan yang berjalan pada port jaringan yang terhubung dengan aplikasi Anda melalui protokol nyata. Orang menyebut layanan virtual HTTP "mock" dalam penggunaan kasual, yang tidak masalah, tetapi perbedaan teknisnya adalah objek dalam proses versus layanan jaringan.
Kapan saya harus menggunakan layanan virtual alih-alih lingkungan pengujian nyata? Gunakan virtualisasi ketika dependensi nyata tidak tersedia, dibatasi laju, mahal, atau sulit dikendalikan. Ini memberi Anda respons yang deterministik, gratis, selalu tersedia, dan memungkinkan Anda mensimulasikan kesalahan yang tidak dapat Anda picu pada sistem nyata. Pertahankan serangkaian pengujian yang lebih kecil terhadap layanan nyata untuk kepercayaan integrasi akhir.
Bisakah layanan virtual berstatus? Ya. Alat seperti WireMock dan Mountebank mendukung skenario berstatus di mana respons berubah berdasarkan permintaan sebelumnya, misalnya mengembalikan keranjang kosong, kemudian keranjang dengan item setelah POST. Ini penting ketika Anda mensimulasikan alur kerja daripada panggilan tunggal.
Apakah saya memerlukan alat perusahaan berbayar? Hanya jika Anda memvirtualisasikan banyak protokol non-HTTP atau mengelola virtualisasi di seluruh organisasi besar. Untuk API HTTP biasa, alat open-source (WireMock, Hoverfly, Mountebank) atau server mock platform API dapat melakukan pekerjaan itu tanpa lisensi perusahaan.
Apa cara tercepat untuk memvirtualisasikan API HTTP dari spesifikasinya? Impor definisi API ke dalam alat yang menghasilkan mock dari skema. Apidog melakukan ini secara otomatis: impor spesifikasi OpenAPI Anda dan Anda mendapatkan server mock yang sadar skema dengan data dinamis yang realistis, tanpa perlu menulis respons. Dari sana Anda menambahkan aturan kustom untuk kondisi permintaan/respons spesifik yang dibutuhkan pengujian Anda.