Mock, stub, fake, dan emulator: menguji panggilan API dengan agen pengkodian

Saat kode Anda memanggil API, Anda memerlukan cara untuk mengujinya tanpa menunggu API nyata gagal. Anda memiliki 5 jenis pengganti untuk dipilih. Orang-orang sering menggunakan istilah-istilah ini secara longgar, jadi, dalam artikel ini, istilah-istilah tersebut digunakan dengan pengertian berikut:

Stub: penggantian dalam proses yang sama untuk klien HTTP atau panggilan SDK Anda yang mengembalikan jawaban kalengan. Ini cepat dan dapat diulang, dan ini menguji logika Anda untuk respons yang Anda tulis.
Mock: stub yang juga merekam cara kode Anda memanggilnya, sehingga pengujian Anda dapat memeriksa pemanggilan tersebut. Itu mencapai sejauh stub.
Server palsu: server kecil yang berfungsi, sering berada di memori, yang dipanggil aplikasi Anda melalui HTTP alih-alih API nyata. Ini menguji klien HTTP Anda, tetapi Anda harus mengarahkan aplikasi Anda ke URL tersebut.
Emulator: versi lokal dari suatu layanan, biasanya disediakan oleh pemilik layanan, yang berfungsi seperti layanan aslinya untuk operasi yang didukungnya. Periksa batasan dan jenis kegagalan yang dicakupnya sebelum Anda mengandalkannya untuk penanganan kesalahan.
Proksi intersepsi: adalah proksi yang berada di antara aplikasi Anda dan API. Aplikasi Anda memanggil URL sebenarnya, dan proksi meneruskan permintaan tersebut atau menjawab sebagian permintaan itu dengan respons yang Anda tentukan sendiri. Aplikasi Anda harus mengirim lalu lintasnya melalui proksi dan, untuk HTTPS, percayai sertifikat proksi.

Cara menguji kode yang memanggil API

Approach	Apa yang diuji	Apa yang dibutuhkan	Tepat ketika
Stub atau mock	Logika Anda untuk respons tertentu	Kerangka kerja pengujian Anda	Anda menguji logika bisnis, parsing, dan alur kesalahan dalam uji unit
Server palsu	Klien HTTP dan serialisasi Anda	Pengaturan URL dasar atau opsi konfigurasi di aplikasi Anda	API belum ada, atau Anda memerlukan backend yang stabil untuk pekerjaan UI
Emulator	Perilaku yang menyerupai layanan nyata untuk operasi yang didukung	Titik akhir atau string koneksi yang berbeda	Pemilik layanan mengirimkan satu unit dan Anda mengembangkan secara offline
Real API dengan akun uji	Yang asli	Kredensial, kuota, dan uang	Anda memverifikasi jalur utama dari ujung ke ujung
Proxy pencegat	Aplikasi Anda yang berjalan pada URL aktual, termasuk percobaan ulang oleh SDK dan header respons	Pengaturan proksi dan sertifikat tepercaya	Anda menguji kegagalan, batas, dan latensi tanpa mengubah aplikasi Anda

Anda membutuhkan lebih dari 1 dari ini. Stubs membuat pengujian unit Anda tetap cepat. Proksi menunjukkan kepada Anda apa yang dilakukan seluruh aplikasi ketika API nyata bermasalah. Untuk informasi selengkapnya tentang bagaimana keduanya saling melengkapi, lihat Dev Proxy vs uji unit.

Apa yang dibuat oleh agen coding

Saat Anda meminta agen coding untuk membuat aplikasi Anda menangani kegagalan API dan menunjukkan bahwa penanganan itu berfungsi, agen tersebut memilih pengganti untuk Anda. Kami ingin tahu yang mana, jadi kami menjalankan tes dengan 3 agen pengkodian (210 eksekusi). Tugas-tugas menggunakan frasa seperti "menangani pembatasan laju dengan benar dan menunjukkan kepada saya bahwa itu berfungsi", "verifikasi tanpa menghabiskan uang untuk panggilan API nyata", dan "jalankan ini tanpa kunci OpenAI atau koneksi internet".

Dalam 76% dari 140 eksekusi yang meminta kode kerja, agen menyusun kegagalan secara manual: stub fetch, httpx.MockTransport, atau server HTTP sekali pakai.
Dalam 61 dari 105 eksekusi pada aplikasi yang memanggil GitHub, OpenAI, atau API cuaca, agen menambahkan URL dasar atau opsi konfigurasi ke aplikasi agar dapat mengakses versi palsunya.
Dalam 75 kali pengujian ketika API asli tersedia dan prompt tidak menutup kemungkinan tersebut, tidak satu pun yang menguji aplikasi menggunakan URL API aslinya.

Stub adalah pilihan yang wajar untuk pengujian unit. Perbedaannya adalah apa yang mereka tinggalkan. Stub agen mengembalikan kesalahan yang diharapkan agen, yang mungkin tidak cocok dengan apa yang dikirim API. Dan sakelar yang ditambahkan untuk mengakses kapal palsu dengan aplikasi Anda.

Cara bekerja dengan tes agen Anda

Simpan stub-stub untuk logika Anda. Mereka cepat, dan mereka menguji cabang yang dibuat agen.
Minta format kesalahan sebenarnya. Minta agen untuk mendasarkan setiap kesalahan yang disimulasikan pada kode status, header, dan bidang isi yang didokumenkan penyedia. Kode/status 429 saja tidak menguji bahwa aplikasi Anda membaca retry-after atau membedakan kesalahan penagihan dengan batas laju.
Tinjau sakelar yang ditambahkan untuk pengujian. Jika agen menambahkan pengaturan URL dasar hanya agar pengujian dapat mengakses layanan tiruan, putuskan apakah Anda menginginkan pengaturan tersebut dalam kode produksi Anda.
Jalankan aplikasi sekali menggunakan URL sungguhan dengan kegagalan yang disimulasikan. Sebelum Anda merilis, periksa apa yang dilakukan aplikasi yang sedang berjalan, SDK-nya, dan kebijakan percobaan ulang dalam menangani error API itu sendiri. Untuk meninjau penanganan kesalahan agen langkah demi langkah, lihat Cara memverifikasi penanganan kesalahan yang ditulis agen pengkodean Anda.

Coba di aplikasi Anda.

Dev Proxy adalah proksi pencegat untuk pengembangan. Ini mengembalikan respons yang Anda tentukan untuk URL yang sudah diakses oleh aplikasi Anda, tanpa perubahan pada kode aplikasi Anda. Aktifkan MockResponsePlugin di konfigurasi Anda, devproxyrc.json:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
  "plugins": [
    {
      "name": "MockResponsePlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "mocksPlugin"
    }
  ],
  "urlsToWatch": [
    "https://api.contoso.com/*"
  ],
  "mocksPlugin": {
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.schema.json",
    "mocksFile": "mocks.json"
  }
}

Kemudian tentukan respons di mocks.json. Yang satu ini mengembalikan 503 dengan Retry-After header untuk titik akhir prakiraan:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.mocksfile.schema.json",
  "mocks": [
    {
      "request": {
        "url": "https://api.contoso.com/v1/forecast*",
        "method": "GET"
      },
      "response": {
        "statusCode": 503,
        "headers": [
          {
            "name": "Retry-After",
            "value": "10"
          }
        ],
        "body": {
          "error": "Service unavailable"
        }
      }
    }
  ]
}

Mulai Dev Proxy dan jalankan aplikasi Anda seperti biasa:

devproxy --config-file devproxyrc.json

Permintaan yang tidak cocok dengan mock diteruskan ke API yang sebenarnya. Saat Anda memerlukan backend yang belum ada, CrudApiPlugin mensimulasikan CRUD API dengan data dalam memori. Untuk menggagalkan sebagian permintaan secara acak alih-alih setiap kali, lihat Uji aplikasi saya dengan kesalahan acak. Untuk menginstal Dev Proxy, lihat Menyiapkan Dev Proxy.

Langkah berikutnya

Respons tiruan

Saran dan Komentar

Apakah halaman ini membantu?

Terakhir diperbarui pada 2026-10-05