Sebagian besar tim tahu cara melakukan mocking pada API. Lebih sedikit yang memiliki jawaban jelas kapan hal itu benar-benar membantu dan kapan hal itu hanya menambah lapisan untuk dipelihara. Mock yang Anda gunakan pada saat yang tepat menghilangkan hambatan nyata. Mock yang Anda buat karena kebiasaan menjadi hal lain yang menyimpang dari kenyataan dan diam-diam membohongi Anda.
Artikel ini tidak membahas 'bagaimana' melainkan berfokus pada 'kapan'. Setiap bagian adalah situasi konkret di mana mocking sangat berguna: membangun dengan backend yang belum selesai, menguji alur error, menggantikan layanan pihak ketiga yang tidak stabil, menjalankan demo, dan menstabilkan CI. Bacalah ini sebagai alat bantu pengambilan keputusan, bukan tutorial.
Pengembangan frontend dan backend secara paralel
Ini adalah kasus klasik. Tim frontend membutuhkan endpoint yang belum dibangun oleh tim backend. Tanpa mock, frontend bisa menunggu atau membuat kode berdasarkan asumsi yang akan rusak saat pertama kali berinteraksi dengan layanan nyata.
Mock memutus ketergantungan. Kedua tim menyepakati kontrak terlebih dahulu, biasanya sebagai dokumen OpenAPI. Frontend membangun berdasarkan mock yang dihasilkan dari kontrak tersebut sementara backend mengimplementasikan hal yang sebenarnya. Ketika backend selesai, frontend menukar URL dasar dan, jika kedua belah pihak menghormati kontrak, tidak ada hal lain yang berubah.
Kesepakatan adalah bagian yang paling penting. Mock yang dibuat oleh frontend saja hanya mengkodekan asumsi satu tim. Mock yang berasal dari spesifikasi bersama menjaga kedua tim tetap selaras, yang merupakan prinsip yang sama di balik pengujian kontrak API. Gunakan mock untuk membuka blokir pekerjaan paralel, tetapi hanya terhadap kontrak yang telah disetujui kedua belah pihak.
Manfaatnya berlipat ganda di seluruh proyek. Tim frontend yang tidak pernah terhambat oleh backend dapat merilis fitur sesuai jadwalnya sendiri. Tim backend yang tidak diganggu untuk endpoint yang belum selesai tetap fokus. Desainer dan manajer produk mendapatkan build yang dapat diklik untuk ditanggapi berminggu-minggu lebih awal. Semua itu tidak memerlukan layanan nyata untuk ada terlebih dahulu. Satu-satunya biaya berkelanjutan adalah menjaga mock tetap selaras dengan kontrak seiring evolusi kontrak, yang murah jika mock dihasilkan dari spesifikasi daripada ditulis tangan.
Menguji jalur error yang tidak dapat Anda picu sesuai permintaan
API yang sehat mengembalikan kode 200. Itulah masalahnya. Kode klien Anda juga harus menangani 429, 500, 503, body yang salah format, dan timeout, dan server yang berfungsi tidak akan menghasilkan hal-hal tersebut saat pengujian Anda memintanya.
Mock menghasilkannya sesuai perintah. Anda mengkonfigurasinya untuk mengembalikan 500 untuk satu permintaan, 429 dengan header Retry-After untuk yang lain, dan body yang tiba setelah penundaan yang disengaja untuk yang ketiga. Kemudian Anda memastikan bahwa logika coba ulang, backoff, dan penanganan timeout Anda semuanya berfungsi dengan baik.
| Kegagalan untuk diuji | Pengaturan Mock | Apa yang dibuktikan |
|---|---|---|
| Error server | Kembalikan 500 |
Klien mencoba lagi, lalu menurun dengan anggun |
| Pembatasan kecepatan (Rate limiting) | 429 dengan Retry-After |
Klien menunggu interval yang benar |
| Jaringan lambat | Tunda respons 5 detik | Klien timeout dengan bersih |
| Payload buruk | Kembalikan JSON rusak | Parser gagal tanpa crash |
Ini adalah kasus penggunaan yang paling sering dilewati tim dan paling disesali. Penanganan error yang belum pernah diuji adalah penanganan error yang tidak Anda miliki. Pasangkan mock dengan asersi API yang menyeluruh agar setiap jalur kegagalan diverifikasi, bukan diasumsikan.
Ada kelas error kedua yang patut di-mock: respons yang merupakan HTTP valid tetapi salah untuk domain Anda. Kode 200 dengan harga negatif, pesanan dengan status yang tidak ada dalam enum Anda, daftar berhalaman yang kursor next -nya tidak menunjuk ke mana pun. Server nyata, jika benar, tidak pernah mengirimkan ini. Mock bisa, dan memberi klien Anda data yang sengaja salah format-tetapi-berformat-baik adalah cara Anda menemukan asumsi yang dibuat kode parsing Anda secara diam-diam.
Menggantikan API pihak ketiga
Memanggil pemroses pembayaran nyata, layanan pemetaan, atau API pengiriman dalam pengujian Anda lambat, terkadang membutuhkan biaya per panggilan, dan tergantung pada layanan yang tidak Anda kontrol. Jika sandbox mereka tidak berfungsi, suite pengujian Anda juga tidak berfungsi.
Lakukan mocking pada pihak ketiga. Anda merekam respons nyatanya sekali, atau membuat mock dari skema yang dipublikasikan, lalu menjalankan pengujian Anda terhadap mock tersebut. Pengujian menjadi cepat, gratis, dan deterministik. Mereka juga tetap berfungsi saat vendor mengalami pemadaman.
Ada biaya pemeliharaan. Pihak ketiga dapat mengubah API-nya tanpa memberi tahu Anda, dan mock Anda tidak akan tahu. Solusinya adalah pekerjaan terjadwal kecil yang memanggil layanan nyata dan mengkonfirmasi bahwa respons masih cocok dengan bentuk mock Anda. Pemeriksaan kontrak itu adalah satu-satunya tempat Anda menyentuh pihak ketiga secara langsung, dan ini menangkap penyimpangan sebelum pengguna Anda mengetahuinya. Ada baiknya juga berlangganan changelog vendor, agar perubahan yang direncanakan sampai kepada Anda sebelum pengujian kontrak yang gagal terjadi.
Mendukung demo dan prototipe
Demo yang memanggil layanan langsung di depan klien adalah sebuah pertaruhan. Kueri yang lambat, hasil yang kosong, atau pemadaman yang tidak menguntungkan mengubah presentasi yang rapi menjadi permintaan maaf.
Mock membuat demo menjadi deterministik. Anda membuat skrip data yang persis dibutuhkan demo: pesanan yang dikirim tepat waktu, dasbor dengan angka yang sehat, pencarian yang mengembalikan hasil bersih. Hal yang sama berlaku untuk prototipe. Anda dapat memvalidasi alur UI atau mengajukan fitur jauh sebelum backend ada, karena mock menyediakan setiap respons yang diharapkan prototipe.
Intinya di sini bukanlah pengujian, melainkan kontrol. Anda memutuskan apa yang dilihat audiens, dan tidak ada hal eksternal yang bisa merusaknya. Untuk pekerjaan tahap awal, mock seringkali merupakan cara tercepat untuk mendapatkan sesuatu yang dapat diklik di depan orang-orang. Alat yang membandingkan di seluruh kategori dibahas dalam tinjauan alat mocking API online ini.
Mock prototipe juga berfungsi ganda sebagai dokumen desain. Ketika mock mengembalikan bentuk yang persis sama dengan yang akan disajikan oleh API akhirnya, kode frontend yang Anda tulis terhadapnya adalah kode nyata, bukan kerangka kerja yang akan dibuang. Jika backend kemudian menghormati kontrak yang sama, prototipe menjadi produk hanya dengan perubahan URL dasar. Itu adalah perbedaan antara mock yang digunakan sebagai penopang dan mock yang digunakan sebagai permulaan yang menguntungkan.
Menjaga CI cepat dan stabil
Suite pengujian yang memanggil layanan eksternal di CI mewarisi setiap masalah yang dimiliki layanan tersebut. Gangguan jaringan, pembatasan kecepatan, data staging bersama yang baru saja diubah oleh build lain: masing-masing berubah menjadi kegagalan yang tidak stabil yang tidak ada hubungannya dengan kode yang sedang ditinjau.
Pengujian yang tidak stabil melatih orang untuk mengabaikan kegagalan, yang menggagalkan tujuan CI. Melakukan mocking pada dependensi eksternal membuat suite bersifat hermetik. Setiap eksekusi dimulai dari keadaan yang diketahui yang sama, selesai lebih cepat karena tidak ada perjalanan bolak-balik jaringan, dan gagal hanya ketika kode benar-benar rusak.
Pertahankan satu pengecualian. Jalankan lapisan tipis pengujian kontrak terhadap API nyata sesuai jadwal, terpisah dari suite per-commit. Hal itu mengkonfirmasi bahwa mock masih cocok dengan produksi. Suite per-commit tetap cepat dan di-mock; pekerjaan terjadwal menangkap penyimpangan. Pembagian ini merupakan inti dari pipeline pengujian CI/CD yang sehat.
Peningkatan kecepatan bukanlah kenyamanan kecil. Suite yang berkurang dari dua belas menit menjadi sembilan puluh detik mengubah cara kerja tim. Pengembang menjalankannya sebelum setiap push alih-alih berharap-harap cemas. Peninjau melihat hasilnya dalam waktu yang dibutuhkan untuk membaca diff. Suite yang cepat dan hermetik adalah salah satu yang benar-benar dipercaya orang, dan kepercayaan adalah seluruh pengembalian investasi dari pengujian otomatis.
Kapan tidak perlu melakukan mocking
Mocking memiliki mode kegagalan: mock yang tidak lagi sesuai dengan kenyataan. Pengujian tetap hijau sementara produksi rusak, karena mereka memvalidasi fiksi.
Jangan melakukan mocking saat yang diuji adalah integrasi itu sendiri. Pengujian kontrak dan pemeriksaan end-to-end ada untuk memverifikasi batas nyata, jadi melakukan mocking pada mereka menghilangkan alasan keberadaan mereka. Jangan melakukan mocking pada dependensi yang tidak pernah Anda verifikasi terhadap hal yang sebenarnya, karena mock yang tidak diverifikasi akan menyimpang. Dan jangan menggunakan mock ketika layanan nyata cepat, gratis, dan dapat diandalkan di lingkungan pengujian Anda; mock hanya akan menjadi beban tambahan.
Aturan praktisnya: lakukan mocking untuk kecepatan, isolasi, dan kontrol, dan pertahankan kumpulan pengujian kecil yang jujur yang menyentuh kenyataan untuk mengkonfirmasi bahwa mock masih benar. Jika Anda ingin mock dan pemeriksaan kontrak berada di satu tempat, Apidog menghasilkan mock dari desain API Anda dan menjalankan pengujian terhadap mock dan endpoint langsung. Untuk mengaturnya, Unduh Apidog dan mulai dari spesifikasi Anda yang sudah ada. Untuk dasar konseptual, lihat apa sebenarnya API mock itu.
Pertanyaan yang sering diajukan
Kapan saya harus melakukan mocking pada API daripada memanggil yang asli?
Lakukan mocking saat Anda membutuhkan kecepatan, isolasi, atau kontrol: pengembangan paralel terhadap backend yang belum selesai, menguji jalur error yang tidak akan dihasilkan oleh server nyata, menggantikan layanan pihak ketiga yang lambat atau berbayar, menjalankan demo, dan menjaga CI tetap stabil. Panggil API nyata untuk pengujian kontrak dan end-to-end.
Apakah mocking menggantikan pengujian integrasi?
Tidak. Mocking adalah untuk pengujian unit dan komponen di mana Anda memeriksa kode Anda sendiri. Pengujian integrasi dan kontrak harus menyentuh batas nyata, karena tugas mereka adalah mengkonfirmasi bahwa layanan aktual cocok dengan kontrak. Melakukan mocking pada hal-hal tersebut menghilangkan tujuannya.
Bagaimana saya menjaga mock agar tidak ketinggalan zaman?
Hasilkan mock dari skema bersama, idealnya OpenAPI, sehingga perubahan kontrak akan memperbarui mock tersebut. Kemudian jalankan pengujian kontrak terjadwal terhadap API nyata untuk mengkonfirmasi bahwa respons langsung masih cocok dengan skema tersebut. Penyimpangan tertangkap sebelum sampai ke pengguna.
Bisakah saya melakukan mocking pada API pihak ketiga yang tidak saya kontrol?
Ya, dan ini adalah salah satu kasus penggunaan terkuat. Rekam respons nyata pihak ketiga atau buat mock dari skema yang dipublikasikan, lalu uji terhadap mock untuk kecepatan dan keandalan. Tambahkan pemeriksaan terjadwal terhadap layanan langsung agar Anda tahu saat vendor mengubah API-nya.
Apakah mocking berguna untuk demo dan prototipe?
Sangat. Mock membuat demo deterministik dengan membuat skrip data yang persis Anda ingin audiens lihat, tanpa risiko dari pemadaman langsung atau data yang tidak menguntungkan. Untuk prototipe, mock memungkinkan Anda membangun dan memvalidasi alur UI sebelum backend ada.