API tiruan (mock API) adalah API palsu yang berperilaku seperti API sungguhan. API ini menerima permintaan yang sama, mengembalikan respons dengan bentuk yang sama, dan berada di URL yang dapat Anda panggil, tetapi di balik URL tersebut tidak ada basis data nyata, tidak ada logika bisnis, dan tidak ada layanan nyata. Responsnya adalah sesuatu yang Anda definisikan sebelumnya.
Kedengarannya sepele, dan memang begitu idenya. Nilainya berasal dari apa yang memungkinkan Anda lakukan: membangun dan menguji terhadap antarmuka sebelum hal di baliknya ada atau saat hal yang sebenarnya terlalu lambat, terlalu mahal, atau terlalu tidak dapat diandalkan untuk dipanggil. Penjelasan ini mendefinisikan istilah tersebut secara tepat, memisahkan mock dari hal-hal yang sering dikelirukan dengannya, dan menguraikan perbedaan statis-versus-dinamis yang menentukan bagaimana sebuah mock berperilaku.
Apa sebenarnya API tiruan (mock API) itu
Singkatnya, API tiruan adalah peta permintaan-ke-respons. Sebuah permintaan masuk. Mock mencocokkannya dengan aturan yang Anda tetapkan, memilih respons, dan mengirimkannya kembali. Tidak ada komputasi di antaranya kecuali Anda memintanya.
Sebuah mock memiliki tiga bagian. Ada antarmuka: rute, metode, dan parameter yang diterimanya, yang harus sesuai persis dengan API nyata. Ada definisi respons: badan, kode status, dan header yang dikembalikannya. Dan ada logika pencocokan: bagaimana mock memutuskan respons mana yang didapatkan dari permintaan tertentu, dari pencocokan jalur sederhana hingga aturan yang bercabang pada parameter kueri atau header.
Karena antarmuka cocok dengan API yang sebenarnya, kode yang memanggil mock tidak tahu bahwa itu palsu. Tukar URL dasarnya dan klien yang sama akan berbicara dengan layanan yang sebenarnya. Sifat saling tukar (interchangeability) itulah intinya. Untuk panduan praktis tentang membangunnya, lihat panduan ini tentang membuat API tiruan untuk pengujian.
Penting untuk tepat mengenai apa yang bukan API tiruan. Ini bukan cache, karena cache menyimpan respons nyata sedangkan mock menciptakannya. Ini bukan kotak pasir (sandbox), karena kotak pasir vendor menjalankan logika nyata yang disederhanakan sementara mock tidak menjalankan logika sama sekali. Dan ini bukan lingkungan staging, karena staging adalah penerapan penuh dari sistem nyata. Mock lebih ringan dari ketiganya: ini hanya pintu depan sebuah API dengan jawaban yang telah ditentukan di baliknya, dan tidak ada yang lain.
Mock versus stub
Orang-orang menggunakan "mock" dan "stub" secara bergantian, tetapi dalam pengujian, keduanya memiliki arti yang berbeda.
Stub adalah ide yang lebih sederhana. Ini mengembalikan jawaban yang telah ditentukan untuk sebuah panggilan dan tidak lebih. Mintalah pengguna, ia mengembalikan pengguna tetap. Stub tidak memiliki pendapat tentang bagaimana ia dipanggil.
Mock, dalam arti pengujian yang ketat, juga memverifikasi interaksi. Ini dapat menegaskan bahwa ia dipanggil, berapa kali, dan dengan argumen apa. Sebuah mock dapat menyebabkan pengujian Anda gagal karena panggilan yang salah, bukan hanya memberikan nilai.
Dalam pekerjaan API sehari-hari garisnya buram, dan "mock API" biasanya mencakup keduanya. Pelajaran pentingnya: stub menjawab, mock menjawab dan mengamati. Ketika pengujian Anda hanya peduli tentang data yang diterima kode Anda, respons bergaya stub sudah cukup. Ketika pengujian peduli apakah kode Anda melakukan panggilan yang benar dengan cara yang benar, Anda menginginkan verifikasi yang ditambahkan oleh mock sejati. Untuk kosakata yang lebih luas, lihat perbedaan antara validasi dan verifikasi.
Dua istilah lagi yang berada di dekatnya. Fake adalah implementasi yang berfungsi tetapi disederhanakan, seperti basis data dalam memori yang digunakan sebagai pengganti yang nyata; ia memiliki logika, hanya saja lebih sedikit. Spy membungkus objek nyata dan merekam bagaimana ia dipanggil tanpa mengubah perilakunya. Mock API, seperti yang digunakan dalam pengembangan API, paling dekat dengan stub dengan verifikasi opsional, yang disajikan melalui HTTP di URL nyata. Anda tidak perlu mengawasi kosakata, tetapi mengetahui spektrumnya membantu Anda membaca dokumentasi pengujian tanpa tersesat.
Mock API versus server nyata
Server nyata dan server mock dapat berada di URL yang sama dan mengembalikan JSON yang sama, jadi perbedaannya adalah apa yang terjadi di balik endpoint.
| Mock API | Server Nyata | |
|---|---|---|
| Di balik endpoint | Respons yang telah ditentukan | Logika langsung dan basis data |
| Sumber respons | Aturan yang Anda tulis | Dihitung per permintaan |
| Data | Tetap atau dihasilkan | Nyata, persisten |
| Efek samping | Tidak ada | Penulisan, tagihan, email |
| Kecepatan | Cepat dan konstan | Bervariasi dengan beban |
| Kebenaran | Sesuai dengan yang Anda definisikan | Sesuai dengan perilaku sebenarnya |
Server nyata memberi tahu Anda kebenaran: ia menjalankan kode yang sebenarnya dan membuktikan sistem bekerja. Ia juga lambat, stateful, dan mampu menimbulkan efek samping nyata, sehingga pengujian terhadapnya dapat menagih kartu atau mengirim email.
Server mock hanya memberi tahu apa yang Anda perintahkan. Ia cepat, bebas efek samping, dan sangat dapat diprediksi, yang menjadikannya ideal untuk pengembangan dan sebagian besar pengujian. Tetapi mock bisa salah dan tidak pernah tahu, karena ia tidak menjalankan logika yang sebenarnya. Itulah mengapa Anda tetap menyimpan beberapa pengujian di server nyata. Pertukaran ini dibahas secara mendalam dalam server mock versus server nyata.
Mock statis dan dinamis
Mock mengembalikan responsnya dengan salah satu dari dua cara, dan pilihan ini membentuk bagaimana mock terasa saat digunakan.
Mock statis mengembalikan payload tetap. Anda menulis JSON yang persis sama sekali, dan setiap permintaan yang cocok akan mendapatkan badan yang identik itu kembali. Mock statis dapat diprediksi, yang membuatnya mudah untuk diuji. Kelemahannya adalah realisme: satu payload hardcoded tidak akan memunculkan bug dalam kode yang rusak pada string panjang, array kosong, atau null yang tidak terduga.
Mock dinamis menghasilkan respons per permintaan. Alih-alih "id": "user_1001" yang tetap, ia menghasilkan UUID baru setiap kali dipanggil. Alih-alih satu nama, ia mengembalikan nama realistis yang berbeda setiap kali. Mock dinamis biasanya menggerakkan ini dengan tata bahasa pembuatan data seperti Faker.js, sehingga bidang bernama email menghasilkan email dan created_at menghasilkan tanggal. Mereka lebih realistis dan lebih baik dalam mengungkap kasus tepi, dengan biaya yang lebih sulit untuk diuji secara tepat.
Sebagian besar tim menggunakan keduanya. Mock statis untuk pengujian unit yang mengandalkan penegasan di mana Anda membutuhkan satu nilai yang diketahui. Mock dinamis untuk pengembangan, demo, dan cakupan gaya fuzz di mana variasi lebih penting daripada jawaban yang tetap.
Mock dinamis juga bisa kondisional, yang merupakan langkah lebih jauh dari pembuatan sederhana. Mock kondisional bercabang pada permintaan: permintaan untuk /orders/404 mengembalikan 404, permintaan dengan token yang buruk mengembalikan 401, dan semuanya mengembalikan 200 normal. Satu endpoint mock kemudian mencakup jalur bahagia dan beberapa jalur kegagalan sekaligus. Inilah yang membuat mock benar-benar berguna untuk pengujian, karena ia dapat mereproduksi respons kesalahan yang tidak akan dihasilkan oleh server nyata yang sehat sesuai permintaan.
Di mana mock API cocok dalam pengembangan
Mock API berguna pada tiga titik. Pada awalnya, ia memungkinkan tim frontend dan backend menyepakati kontrak dan membangun secara paralel, sehingga tidak ada yang menunggu satu sama lain. Selama pengujian, ia mengisolasi kode Anda dari ketidakstabilan jaringan dan memungkinkan Anda memicu respons kesalahan yang tidak akan dihasilkan oleh server nyata sesuai permintaan. Dan untuk demo serta prototipe, ia menyediakan data yang terkontrol, dapat diprediksi tanpa dependensi langsung yang dapat gagal di tengah presentasi. Skenario-senario tersebut dijelajahi lebih lanjut dalam panduan ini untuk kasus penggunaan mocking API.
Risiko yang berulang adalah penyimpangan (drift). Mock adalah snapshot antarmuka, dan antarmuka berubah. Ketika API yang sebenarnya menambahkan bidang atau mengganti nama satu, mock yang terputus terus menyajikan bentuk lama dan pengujian Anda lulus terhadap kontrak yang sudah tidak ada lagi.
Solusinya adalah memperlakukan mock sebagai turunan, bukan yang dibuat secara manual. Hasilkan dari skema yang sama yang diterbitkan API nyata, sehingga perubahan kontrak akan meregenerasi mock. Mock yang Anda ketik secara manual adalah salinan yang segera mulai menua; mock yang dihasilkan dari spesifikasi selalu merupakan snapshot terkini. Perbedaannya tidak terlihat pada hari pertama, tetapi ini menentukan apakah mock masih dapat dipercaya enam bulan kemudian. Apidog bekerja dengan cara ini: Anda merancang API sekali, dan endpoint mock dihasilkan dari desain itu dengan data realistis yang disimpulkan dari nama bidang. Mock, dokumentasi, dan pengujian kontrak API semuanya membaca dari satu sumber, sehingga tetap sinkron. Untuk melihat alur desain-ke-mock secara menyeluruh, Unduh Apidog.
Pertanyaan yang Sering Diajukan
Apa itu mock API dalam istilah sederhana?
Mock API adalah API palsu yang meniru API nyata. Ini mengekspos rute yang sama dan mengembalikan respons dengan bentuk yang sama, tetapi tidak ada logika atau basis data nyata di baliknya. Responsnya telah ditentukan sebelumnya, yang memungkinkan Anda membangun dan menguji antarmuka sebelum layanan nyata ada.
Apa perbedaan antara mock dan stub?
Stub mengembalikan respons yang telah ditentukan dan tidak ada yang lain. Mock, dalam arti pengujian yang ketat, juga memverifikasi interaksi, sehingga dapat memeriksa apakah ia dipanggil dengan jumlah yang benar dan argumen yang tepat. Stub menjawab; mock menjawab dan mengamati.
Bagaimana mock API berbeda dari server nyata?
Mock mengembalikan respons yang telah ditentukan tanpa komputasi nyata, sehingga cepat, dapat diprediksi, dan tidak memiliki efek samping. Server nyata menjalankan logika aktual terhadap basis data nyata, sehingga lebih lambat dan stateful tetapi membuktikan sistem benar-benar bekerja. Gunakan mock untuk pengembangan, dan server nyata untuk pengujian kontrak dan end-to-end.
Haruskah saya menggunakan mock statis atau dinamis?
Gunakan mock statis ketika Anda membutuhkan satu nilai yang dapat diprediksi untuk diuji, yang cocok untuk pengujian unit. Gunakan mock dinamis ketika Anda menginginkan data realistis yang bervariasi yang menangkap kasus tepi, yang cocok untuk pengembangan dan demo. Banyak tim menggunakan keduanya.
Bagaimana cara menghentikan mock API agar tidak menjadi tidak akurat?
Hasilkan mock dari skema yang sama yang diterbitkan API nyata daripada menuliskannya secara manual. Ketika kontrak berubah, mock akan diregenerasi. Mendukungnya dengan pengujian kontrak terjadwal terhadap API nyata menangkap setiap penyimpangan yang tersisa sejak awal.