Blog

Cara Menggunakan Kueri Database untuk Tes API dengan Apidog (MySQL, MongoDB, Redis)

Pelajari cara menggunakan kueri basis data dalam pengujian API dengan Apidog: mengisi data awal, memverifikasi baris terhadap MySQL, MongoDB, dan Redis, dan mengekstrak nilai DB antar langkah.

INEZA Felin-Michel

INEZA Felin-Michel

15 July 2026

Cara Menggunakan Kueri Database untuk Tes API dengan Apidog (MySQL, MongoDB, Redis)

Apidog untuk Perusahaan

Penerapan On-Premises

SSO & RBAC

Sesuai SOC 2

Jelajahi Apidog Enterprise

Kode status hijau itu bohong. Endpoint POST /orders Anda mengembalikan 201 Created, badan respons terlihat sempurna, dan pengujian Anda berhasil. Tapi apakah baris tersebut benar-benar mendarat di database dengan status yang benar? Apakah hitungan inventaris berkurang? Pengujian yang hanya membaca respons HTTP memeriksa apa yang API katakan, bukan apa yang sistem lakukan. Untuk menutup celah itu, Anda harus melihat database itu sendiri.

Di situlah kueri database di dalam skenario pengujian mendapatkan nilainya. Anda menyemai status yang diketahui sebelum permintaan, melakukan permintaan, lalu mengueri tabel untuk mengonfirmasi kebenaran di disk. Apidog memiliki ini terintegrasi melalui Koneksi Database dan prosesor Operasi Database, sehingga Anda dapat menjalankan perintah SQL atau NoSQL sebagai langkah-langkah dalam skenario yang sama yang menjalankan panggilan HTTP Anda, tanpa perlu skrip eksternal. Jika Anda baru dalam membangun skenario, panduan cara menulis skenario pengujian dengan Apidog mencakup dasar-dasar tingkat permintaan yang dibangun oleh artikel ini. Untuk penyegaran tentang bagaimana penyimpanan relasional memodelkan data ini, ikhtisar sisi server MDN adalah pengantar yang kuat.

tombol

Manfaat operasi database dalam pengujian

Pengujian API yang tidak pernah menyentuh database adalah kotak hitam. Ia memercayai respons. Sebagian besar waktu itu baik-baik saja, tetapi bug menarik hidup di celah antara apa yang dikembalikan API dan apa yang dipertahankannya: bidang status yang tidak pernah berubah, kunci asing yang tidak menunjuk ke mana-mana, penghapusan lunak yang menjadi penghapusan keras.

Langkah-langkah database memungkinkan Anda melakukan tiga hal yang tidak bisa dilakukan oleh pengujian HTTP murni:

Apidog membagi fitur ini menjadi dua. Pertama Anda membuat koneksi yang dapat digunakan kembali di bawah Pengaturan > Koneksi Database. Kemudian Anda melampirkan langkah Operasi Database ke permintaan sebagai Pre Processor (berjalan sebelum permintaan) atau Post Processor (berjalan setelah). Satu koneksi, digunakan kembali di setiap skenario dalam proyek.

Catatan tentang cakupan sebelum Anda merencanakannya. MySQL, SQL Server (2014 dan yang lebih baru), PostgreSQL, dan Oracle berfungsi di paket gratis. ClickHouse, MongoDB, dan Redis berbayar. Dokumentasi MongoDB mengatakannya dengan jelas: menghubungkan ke MongoDB adalah fitur berbayar. Sama halnya untuk Redis. Jadi, panduan MySQL di bawah ini berjalan di tingkatan gratis; bagian Mongo dan Redis memerlukan paket berbayar.

Langkah 1: Buat koneksi database

Buka Pengaturan > Koneksi Database dan klik + Baru di kanan atas. Pilih jenis database Anda, lalu isi kolom koneksi:

Jika database Anda berada di belakang bastion, perluas bagian SSH Tunnel dan tambahkan detail jump-host. MySQL juga mengekspos mode SSL dengan empat opsi: Prefer (default, yang mencoba SSL lalu kembali ke mode lain), Require, Verify CA, dan Verify Full. Pilih yang paling ketat yang didukung server Anda. Lalu klik Simpan.

Dua jebakan koneksi yang dapat menyelamatkan Anda dari sore yang membingungkan:

Langkah 2: Menyemai data dengan Pre Processor

Misalnya Anda menguji alur pembuatan pesanan. Anda ingin pelanggan yang dikenal sudah ada sebelum Anda melakukan pemesanan, sehingga pengujian tidak bergantung pada apa pun yang ada di tabel.

Buka permintaan Anda, temukan Pre Processor, arahkan kursor ke Tambah Prosesor Database, dan pilih operasi Database. Beri nama seperti seed customer, pilih koneksi MySQL Anda, lalu di bawah Masukkan Perintah SQL tulis pernyataan insert. Variabel dinamis menggunakan sintaks {{variable_name}}, sehingga Anda dapat menarik nilai langsung dari lingkungan Anda:

INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';

Sekarang permintaan berjalan terhadap status yang dijamin. Pelanggan ada, aktif, dan memiliki ID yang sudah diketahui langkah-langkah selanjutnya. Penyemaian di Pre Processor menjaga setiap pengujian mandiri alih-alih bergantung pada efek samping urutan pengujian.

Langkah 3: Memastikan kebenaran terhadap database dengan Post Processor

Ini intinya. Permintaan Anda membuat pesanan. Setelah respons kembali, Anda mengueri tabel orders untuk mengonfirmasi bahwa baris tersebut ada dengan status yang benar.

Tambahkan permintaan yang memanggil API Anda:

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}

Asumsikan badan respons membawa ID pesanan baru, yang Anda tangkap ke dalam variabel bernama order_id dengan pernyataan respons normal. Sekarang buka Post Processor pada permintaan tersebut. Dalam Mode DESAIN Anda akan menemukannya di tab Run; dalam Mode DEBUG mereka ada di tab Request. Arahkan kursor ke Tambah PostProcessor, pilih operasi Database, beri nama verify order row, dan pilih koneksi Anda.

Di bawah Konfigurasi Operasi, pilih operasi dan masukkan SQL:

SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};

Hasil kueri kembali sebagai array objek, satu per baris. Untuk mengeluarkan satu bidang, buka Ekstrak Hasil (Opsional) dan tambahkan entri Ekstrak Hasil ke Variabel. Tetapkan Nama Variabel seperti db_order_status dan Ekspresi JSONPath yang mengisolasi bidang dari baris pertama:

$[0].status

Klik Kirim dan periksa Konsol untuk melihat hasil mentah dan nilai yang diekstrak. Sekarang db_order_status menyimpan apa yang sebenarnya ada di disk. Tambahkan pernyataan bahwa itu sama dengan pending (atau apa pun yang seharusnya diatur oleh API Anda), dan pengujian Anda akhirnya memverifikasi persistensi, bukan hanya gema HTTP. Jika API mengembalikan 201 tetapi menulis status = 'draft', ini adalah langkah yang menangkapnya.

Langkah 4: Mengekstrak nilai database dan menggunakannya di alur selanjutnya

Ekstraksi bukan hanya untuk pernyataan. Seringkali database menyimpan nilai yang tidak pernah dikembalikan respons, dan Anda membutuhkannya untuk permintaan berikutnya.

Bayangkan alur di mana membuat pesanan juga menghasilkan fulfillment_ref internal di server, ditulis ke baris tetapi dihilangkan dari respons API. Permintaan Anda berikutnya, GET /api/fulfillments/{ref}, membutuhkannya. Kueri untuk itu di Post Processor:

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};

Ekstrak dengan Nama Variabel fulfillment_ref dan Ekspresi JSONPath $[0].fulfillment_ref. Karena Apidog mencakup variabel itu ke lingkungan, permintaan Anda berikutnya hanya mereferensikan {{fulfillment_ref}} di jalurnya atau badannya dan mengambil nilai nyata yang dihasilkan server. Ini adalah pola yang sama dengan merantai respons HTTP, yang dibahas dalam melewatkan data antar langkah pengujian dan orkestrasi pengujian API dan melewatkan data, kecuali sumber kebenarannya adalah tabel, bukan badan JSON.

MongoDB dan Redis: Varian NoSQL

Prosesor bekerja dengan cara yang sama untuk penyimpanan NoSQL, dengan permukaan konfigurasi yang berbeda. Keduanya adalah fitur berbayar, jadi rencanakanlah dengan tepat. Dokumentasi Apidog memiliki referensi bidang lengkap jika Anda membutuhkannya.

MongoDB

Tambahkan langkah Operasi Database dan pilih MongoDB sebagai jenisnya. Alih-alih SQL mentah, Anda mendapatkan dropdown Tipe Operasi dengan Temukan, Sisipkan, Perbarui, Hapus, dan Jalankan Perintah Database. Untuk setiap tindakan CRUD, Nama Koleksi adalah wajib. Kolom Kondisi Kueri menerima JSON:

{ "_id": "65486728456e79993a150f1c" }

Apidog mengonversi string ID yang cocok menjadi ObjectId secara otomatis, jadi Anda tidak perlu membungkusnya sendiri. Saat Anda membutuhkan tipe BSON, pembantu ISODate(...), ObjectId(...), NumberDecimal(...), dan NumberLong(...) didukung; manual MongoDB mendokumentasikan bagaimana masing-masing ini memetakan ke nilai yang disimpan. Koneksi menerima string koneksi penuh atau komponen host dan kredensial individual.

Satu catatan jujur: alur MySQL mendokumentasikan ekstraksi JSONPath ke dalam variabel, tetapi dokumen MongoDB dan Redis tidak menjelaskan mekanisme Ekstrak Hasil ke Variabel yang sama itu. Jadi, andalkan operasi Mongo untuk menyemai dan mengonfirmasi status, dan jangan berasumsi jalur ekstraksi gaya SQL bekerja secara identik sampai Anda memverifikasinya di Konsol.

Redis

Koneksi Redis meminta Host, Port, Kata Sandi, dan Indeks Database. Operasi visual menggunakan dropdown Tipe Operasi yang mendukung GET, SET, dan DELETE. Untuk membaca sesi yang di-cache, pilih GET dan atur Kunci ke sesuatu seperti user:session:123. Untuk apa pun yang tidak tercakup oleh dropdown, tab Jalankan Perintah Redis menjalankan perintah valid apa pun:

KEYS user:*

Begitulah cara Anda mengonfirmasi entri cache yang seharusnya ditulis API, atau menghapus satu sebelum pengujian untuk membuktikan bahwa endpoint mengisinya kembali.

Variasi dan Batasan Lanjutan

Beberapa hal yang perlu diketahui sebelum Anda membangun suite yang besar:

Menangani kredensial per lingkungan

Anda tidak ingin pengujian secara tidak sengaja mengenai data produksi. Jawaban Apidog adalah satu Koneksi Database per lingkungan. Anda membuat koneksi staging dan koneksi local, masing-masing dengan host dan kata sandi sendiri.

Kemudian Anda beralih lingkungan menggunakan dropdown di sudut kanan atas. Apidog secara otomatis merutekan setiap kueri dalam skenario ke koneksi yang cocok dengan lingkungan yang saat ini dipilih. Pilih staging dan SELECT Anda berjalan melawan staging; beralih ke local dan langkah yang sama persis berjalan melawan database laptop Anda, tanpa pengeditan pada SQL atau langkahnya. Kredensial berbeda per lingkungan tanpa konfigurasi ulang manual di tengah jalan.

Karena kredensial tersebut hidup secara lokal dan tidak disinkronkan, ini juga menjaga kata sandi produksi jauh dari proyek cloud bersama. Setiap insinyur memegang miliknya sendiri.

Mengotomatiskan alur kerja dengan Apidog CLI

Setelah skenario berhasil di aplikasi, jalankan tanpa kepala (headless) di CI sehingga setiap pull request memverifikasi ulang database, bukan hanya kontrak HTTP. Instal CLI dan autentikasi:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Kemudian jalankan skenario persis yang Anda buat, berdasarkan ID-nya, terhadap lingkungan yang dipilih:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Di sini -t adalah ID skenario pengujian, -e adalah ID lingkungan, dan -r adalah reporter (cli, html, atau junit; pisahkan dengan koma untuk beberapa, seperti -r html,cli). Satu hal yang perlu direncanakan: detail koneksi database bersifat lokal, jadi runner memerlukan konfigurasi yang diekspor untuk mencapai database Anda dari CI. Jika Anda mengisi baris skenario dari dataset, pengujian berbasis data dengan Apidog CLI menunjukkan bagaimana setiap baris menjalankan pernyataan database yang sama, dan penjadwalan pengujian API dengan Apidog mencakup menjalankan ini secara berkala sehingga pernyataan database yang gagal muncul seperti pengujian lainnya.

Pertanyaan yang Sering Diajukan

Database mana yang gratis dan mana yang berbayar? MySQL, SQL Server (2014 dan yang lebih baru), PostgreSQL, dan Oracle ada di paket gratis. ClickHouse, MongoDB, dan Redis memerlukan paket berbayar. Dokumen MongoDB dan Redis keduanya menyatakan bahwa konektivitasnya adalah fitur berbayar, jadi periksa halaman harga sebelum merencanakan suite NoSQL. Unduh Apidog untuk mencoba database gratis terlebih dahulu.

Dapatkah saya menggunakan nilai dari database dalam permintaan selanjutnya? Ya. Tambahkan Post Processor dengan operasi Database, jalankan SELECT, lalu gunakan Ekstrak Hasil ke Variabel dengan Nama Variabel dan Ekspresi JSONPath seperti $[0].fulfillment_ref untuk mengisolasi bidang dari baris pertama. Referensi nanti sebagai {{nama_variabel}}. Ide merangkai yang sama untuk respons HTTP dibahas dalam melewatkan data antar langkah pengujian.

Apakah rekan tim saya secara otomatis mendapatkan koneksi database saya? Tidak. Kredensial koneksi disimpan secara lokal di setiap klien dan tidak disinkronkan ke cloud, sehingga setiap anggota tim mengonfigurasi koneksi sendiri. Ini disengaja: ini menjaga kata sandi produksi jauh dari proyek bersama.

Koneksi MySQL 8 saya terus gagal. Mengapa? MySQL 8 secara default menggunakan plugin autentikasi caching_sha2_password, yang dapat memblokir koneksi. Ganti pengguna ke mysql_native_password dengan ALTER USER ... IDENTIFIED WITH mysql_native_password dan sambungkan kembali.

Dapatkah saya menjalankan prosedur tersimpan atau logika database kompleks? Tidak melalui antarmuka visual. Ia menangani pernyataan SELECT, INSERT, UPDATE, dan DELETE standar, tetapi operasi kompleks seperti prosedur tersimpan tidak didukung. Jaga agar langkah pengujian Anda tetap pada pernyataan langsung.

Kesimpulan

Kueri database mengubah pengujian API dari “respons terlihat benar” menjadi “data sebenarnya benar.” Semai status yang diketahui di Pre Processor, verifikasi baris yang disimpan di Post Processor, dan ekstrak nilai yang dihasilkan server untuk dirangkai ke permintaan berikutnya, semuanya dalam satu skenario. Siapkan satu koneksi per lingkungan dan langkah-langkah yang sama akan berjalan dengan aman terhadap staging atau lokal tanpa pengeditan.

Coba gratis, tanpa kartu kredit: Unduh Apidog, arahkan koneksi MySQL ke database dev Anda, dan tambahkan satu Post Processor yang membaca kembali baris yang dibuat oleh permintaan berikutnya.

Mengembangkan API dengan Apidog

Apidog adalah alat pengembangan API yang membantu Anda mengembangkan API dengan lebih mudah dan efisien.

Daftar gratisUnduh