Apidog CLI vs Postman CLI: Alat Uji CI Terbaik

Tes API Anda berhasil saat Anda mengklik Jalankan di laptop Anda. Itu tidak membuktikan apa-apa. Tes yang penting adalah tes yang berjalan pada setiap permintaan penarikan (pull request), setiap penggabungan (merge), dan setiap build malam (nightly build), tanpa kehadiran manusia untuk mengklik apa pun. Tugas untuk memasukkan tes Anda ke dalam lingkaran tersebut adalah milik command-line runner. Ini mengambil tes yang sudah Anda tulis, menjalankannya tanpa antarmuka grafis (headless) di dalam pipeline Anda, keluar dengan kode status yang dapat dibaca oleh CI Anda, dan menulis laporan yang muncul di dasbor build.

Dua runner sering muncul ketika tim menyiapkan ini: Postman CLI dan Apidog CLI. Keduanya memiliki tujuan yang sama dari titik awal yang berbeda. Postman CLI menjalankan koleksi yang Anda buat di Postman. Apidog CLI menjalankan skenario tes visual yang Anda buat di Apidog. Keduanya diinstal dalam satu langkah, keduanya dapat terhubung ke GitHub Actions, GitLab CI, dan Jenkins, dan keduanya mengubah build menjadi merah (gagal) ketika tes gagal. Perbedaan sebenarnya terletak sebelum perintah `run`: bagaimana Anda membuat tes, bagaimana Anda mengautentikasi di CI, dan di mana definisi tes sebenarnya berada.

💡

Ini adalah perbandingan tingkat perintah dari keduanya. Tidak ada argumen palsu. Postman CLI melakukan beberapa hal dengan baik, dan Anda akan melihat dengan tepat di mana setiap runner cocok sebelum Anda memasukkannya ke dalam pipeline Anda. Jika Anda baru mengenal Apidog, ini adalah platform API lengkap yang mencakup desain, debugging, pengujian, mocking, dan dokumentasi dalam satu ruang kerja, dan CLI adalah bagian yang membawa tes Anda ke otomatisasi.

tombol

TL;DR

Postman CLI (binary `postman`) menjalankan koleksi yang tersimpan di ruang kerja Postman Anda. Ini berdasarkan Newman, ditandatangani dan didukung oleh Postman, dan mengautentikasi dengan kunci API Postman. Saat Anda masuk, ini secara otomatis mengirimkan hasil eksekusi kembali ke cloud Postman.
Apidog CLI (`apidog-cli`, binary `apidog`) menjalankan skenario tes yang Anda rancang secara visual di Apidog. Anda menunjuknya ke skenario berdasarkan ID dengan token akses, dan ini menjalankan skenario tersebut secara headless tanpa GUI.
Keduanya mengeluarkan laporan JUnit, JSON, HTML, dan terminal. Keduanya menggagalkan build pada tes yang gagal. JUnit XML adalah yang terhubung ke dasbor CI dalam kedua kasus.
Pilih Postman CLI ketika tes Anda sudah berada di koleksi Postman dan tim Anda berkomitmen pada cloud Postman untuk pelaporan dan riwayat.
Pilih Apidog CLI ketika Anda menginginkan pembuatan skenario visual, perantaian permintaan (request chaining), manajemen lingkungan, dan eksekusi berbasis data dari satu sumber kebenaran (single source of truth), dengan kontrol penuh apakah laporan tetap lokal atau pergi ke cloud.

Masalah sebenarnya: tes yang ada tetapi tidak pernah berjalan

Tes yang Anda jalankan secara manual adalah tes yang membusuk. Seseorang menulisnya, berhasil sekali, dan kemudian dibiarkan tidak tersentuh sementara API berubah. Tiga bulan kemudian tes tersebut salah dan tidak ada yang menyadarinya, karena tidak ada yang menjalankannya. Solusinya bukanlah menulis lebih banyak tes. Ini adalah membuat tes yang Anda miliki berjalan secara otomatis pada setiap perubahan, dengan sinyal lulus atau gagal yang dapat ditindaklanjuti oleh pipeline.

CLI runner adalah alat yang menutup celah tersebut. Untuk mendapatkan tempat di CI, ia harus melakukan tiga hal. Ia harus berjalan tanpa GUI, karena runner CI Anda tidak memiliki layar. Ia harus keluar dengan kode non-nol ketika sesuatu gagal, sehingga build menjadi merah dan merge yang rusak diblokir. Dan ia harus menulis laporan yang dapat dibaca mesin, sehingga peninjau melihat apa yang rusak tanpa menjalankan ulang apa pun secara lokal. Postman CLI dan Apidog CLI keduanya melewati batasan itu dengan bersih. Perbedaan mereka terletak pada semua yang terjadi sebelum `run`: bagaimana tes itu ditulis, dan di mana ia berada ketika CI mencarinya.

Jika Anda menyiapkan pengujian otomatis dari awal, pola yang lebih luas dalam mengotomatiskan tes API di CI/CD layak dibaca bersamaan dengan artikel ini. Di sini, fokus tetap pada kedua runner.

Apa yang Postman CLI lakukan dengan baik

Pertama, poin klarifikasi yang membingungkan banyak orang: Postman CLI bukanlah Newman. Newman adalah runner yang lebih tua, open-source, berbasis npm yang telah digunakan komunitas selama bertahun-tahun. Postman CLI adalah alat yang lebih baru, dibangun di atas fondasi Newman, tetapi ditandatangani dan didukung secara resmi oleh perusahaan Postman. Jika Anda telah menjalankan Newman, keduanya tidak dapat dipertukarkan, dan perbedaannya penting di CI. Kami telah menulis perbedaan persis itu di Postman CLI vs Newman jika Anda memutuskan antara dua opsi sisi Postman.

Kekuatan terbesar Postman CLI adalah ia tetap berada di dunia yang sudah dikenal tim Anda. Jika koleksi, lingkungan, dan variabel bersama Anda sudah ada di ruang kerja Postman, CLI menjalankannya hampir tanpa terjemahan. Anda tidak membangun ulang apa pun. Anda mengautentikasi, menamai koleksi, dan ia menjalankan permintaan dan tes persis seperti yang dilakukan aplikasi.

Menginstalnya adalah satu perintah. Di macOS dan Linux Anda menjalankan skrip instalasi resmi:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

Di Windows Anda menggunakan penginstal PowerShell yang ditandatangani, dan ada juga paket npm jika Anda lebih suka menguncinya sebagai dependensi dev:

npm install -g postman-cli

Binary-nya adalah `postman`. Di CI Anda mengautentikasi dengan kunci API Postman, yang merupakan metode yang direkomendasikan Postman untuk pipeline:

postman login --with-api-key $POSTMAN_API_KEY

Kemudian Anda menjalankan koleksi berdasarkan ID-nya, atau berdasarkan jalur file lokal jika Anda telah mengekspornya:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Bagian yang membuat Postman CLI mendapatkan banyak loyalitas adalah apa yang terjadi setelah eksekusi. Saat Anda masuk, ia mengirim hasil eksekusi langsung ke cloud Postman, di mana hasil tersebut muncul di ruang kerja Anda bersama dengan koleksi. Riwayat tes, perbandingan eksekusi, dan dasbor yang terlihat oleh tim semuanya ada di sana tanpa pengaturan tambahan. Bagi tim yang sudah terbiasa dengan Postman, perjalanan pulang pergi ini sangat berguna, dan merupakan alasan yang adil untuk bertahan.

Apa yang Apidog CLI lakukan dengan baik

Apidog mengambil rute yang berbeda ke pipeline yang sama. Anda membuat tes secara visual di dalam aplikasi Apidog: merangkai beberapa permintaan menjadi satu skenario tes, menambahkan pernyataan pada setiap respons, mengambil nilai dari satu respons dan memasukkannya ke permintaan berikutnya, dan mengulang seluruh skenario di atas file data. CLI adalah eksekutor headless untuk skenario-skenario tersebut. Ia tidak memiliki format tes sendiri. Ia mengakses proyek Apidog Anda, menemukan skenario yang Anda sebutkan berdasarkan ID, dan menjalankannya persis seperti yang akan dilakukan aplikasi, lalu melaporkan hasilnya.

Manfaatnya adalah tidak ada yang memelihara dua salinan dari tes yang sama. Skenario yang Anda bangun di editor visual adalah tes yang berjalan di CI. Tidak ada langkah di mana Anda mengekspresikan ulang tes yang berfungsi sebagai skrip lalu melakukan debug skrip tersebut. Lingkaran penulisan yang cepat dan lingkaran otomatisasi berbagi satu sumber kebenaran. Untuk alur multi-langkah, seperti login lalu buat lalu baca lalu hapus, perantaian visual itu menghemat banyak kode penghubung yang sebaliknya akan Anda tulis secara manual. Mekanisme membangun alur tersebut tercakup dalam panduan skenario tes untuk otomatisasi tes API.

Instalasi adalah satu perintah npm:

npm install -g apidog-cli

Binary-nya adalah `apidog`. Sebuah eksekusi tipikal menamai skenario berdasarkan ID, memilih lingkungan, mengatur jumlah iterasi, dan mengautentikasi dengan token akses:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

Anda tidak mengetik ID tersebut secara manual. Buka skenario tes di Apidog, beralih ke tab CI/CD-nya, klik untuk membuat token akses, dan Apidog akan membangun perintah lengkap untuk Anda dengan ID skenario dan ID lingkungan sudah terisi. Anda menyalinnya sekali, memindahkan token ke rahasia CI, dan mereferensikannya sebagai `$APIDOG_ACCESS_TOKEN` dalam alur kerja Anda.

Model token-dan-ID adalah pemisahan paling jelas dari Postman CLI. Apidog menjalankan tes yang disimpan dalam proyek yang diambil CLI melalui jaringan, diautentikasi oleh token. Tidak ada opt-in cloud terpisah untuk pelaporan: Anda memilih `--out-dir` untuk artefak lokal dan menambahkan `--upload-report` hanya ketika Anda ingin ringkasan didorong ke cloud Apidog. Laporan tetap berada di tempat Anda meletakkannya.

Perbandingan berdampingan

Dimensi	Postman CLI (`postman`)	Apidog CLI (`apidog`)
Paket / instalasi	Skrip instalasi, penginstal bertanda tangan, atau `npm i -g postman-cli`	`npm i -g apidog-cli`
Perintah eksekusi	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
Sumber tes	Koleksi di ruang kerja Postman Anda (atau file yang diekspor)	Skenario tes di proyek Apidog Anda, diambil berdasarkan ID
Penulisan	Editor koleksi dan aplikasi Postman	Pembangun skenario visual di aplikasi Apidog
Autentikasi di CI	Kunci API Postman (`postman login --with-api-key`)	Token akses (`--access-token`)
Pilih apa yang dieksekusi	ID koleksi atau jalur file	`-t` skenario, `-f` folder, `--test-suite`
Lingkungan	`-e, --environment`	`-e, --environment <environmentId>`
Berbasis data	`-d, --iteration-data` (JSON atau CSV)	`-d, --iteration-data` (JSON atau CSV)
Iterasi	`-n, --iteration-count`	`-n, --iteration-count`
Pelapor	`cli`, `json`, `junit`, `html`	`cli`, `html`, `json`, `junit`
Gagal cepat	`--bail`	`--on-error end` (default berhenti pada kegagalan pertama)
Pelaporan cloud	Otomatis mengirim hasil saat masuk	Pilih ikut serta melalui `--upload-report`
Dibangun di atas	Newman	Mesin Apidog sendiri

Dua hal menonjol dari tabel itu. Pertama, kedua runner mencakup hal-hal penting CI dalam bentuk yang hampir sama: pemilihan lingkungan, iterasi berbasis data, empat format laporan yang penting, dan keluar non-nol pada kegagalan. Jika yang Anda butuhkan hanyalah runner yang menjadi merah pada merge yang buruk, salah satu dari keduanya akan melakukannya. Kedua, pemisah sebenarnya adalah tentang di mana tes itu berada dan bagaimana Anda menuliskannya. Postman CLI menjalankan koleksi yang ada di ruang kerja Postman Anda. Apidog CLI menjalankan skenario visual yang ada di proyek Apidog Anda.

Pelapor dan kode keluar: bagian yang sebenarnya dibaca oleh CI

Sebuah runner membuktikan nilainya dalam pipeline melalui dua perilaku: laporan yang ditulisnya, dan kode keluar yang dikembalikannya. Dapatkan keduanya dengan benar dan yang lainnya hanyalah kabel.

Postman CLI mengambil daftar pelapor yang dipisahkan koma, dan ketika Anda masuk, ia juga mengirimkan hasilnya ke cloud Postman:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

Pelapor `junit` adalah yang diurai oleh dasbor CI Anda menjadi pohon lulus atau gagal. Flag `--bail` menghentikan eksekusi pada permintaan, tes, atau pernyataan yang gagal pertama kali, yang menjaga umpan balik tetap cepat pada tes smoke. Hilangkan `--bail` dan ia akan menjalankan semuanya, lalu melaporkan semua kegagalan bersama-sama. CLI keluar dengan kode non-nol pada kegagalan apa pun, sehingga build menjadi merah dengan sendirinya.

Apidog CLI menggunakan ide pelapor `-r` yang sama dan menulis semuanya di bawah satu direktori output:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

Flag `--on-error`-nya membentuk perilaku tengah skenario: `end` berhenti pada kegagalan pertama dan merupakan default, `continue` menjalankan setiap langkah sehingga Anda mengumpulkan semua kegagalan dalam satu laporan, dan `ignore` melewati langkah yang diketahui tidak stabil tanpa menggagalkan eksekusi. Bagaimanapun, proses berakhir non-nol jika ada yang gagal, dan JUnit XML mendarat di `./apidog-reports` siap untuk diambil oleh dasbor Anda.

Inti praktisnya: keduanya menulis JUnit XML, keduanya menggagalkan build dengan benar, dan keduanya mengarsipkan laporan HTML yang dapat Anda buka nanti. Perbedaan dalam pelaporan adalah perjalanan pulang-pergi ke cloud. Postman mendorong hasil ke cloud-nya secara default saat Anda diautentikasi. Apidog menyimpan laporan secara lokal kecuali Anda memintanya untuk mengunggah. Keduanya tidak lebih baik secara abstrak; satu cocok untuk tim yang menginginkan riwayat yang di-hosting tanpa memikirkannya, yang lain cocok untuk tim yang ingin memutuskan dengan tepat apa yang meninggalkan runner.

Menghubungkan masing-masing ke GitHub Actions

Bentuk pekerjaan GitHub Actions sama untuk keduanya: check out repo, siapkan Node, instal CLI, jalankan tes, dan kode keluar yang gagal akan memblokir merge. Simpan rahasia di pengaturan repositori Anda, jangan pernah di file alur kerja.

Berikut adalah versi Postman CLI:

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

Dan versi Apidog CLI:

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

Keduanya pendek, keduanya mudah dibaca, dan keduanya berperilaku sama pada tingkat yang penting bagi pipeline Anda: eksekusi yang berhasil keluar dengan kode nol dan merge dilanjutkan, eksekusi yang gagal keluar dengan kode non-nol dan merge diblokir. Jika Anda menginginkan panduan yang lebih mendalam tentang menjalankan tes API dalam alur kerja GitHub, otomatisasi tes API dengan GitHub Actions menjelaskan langkah demi langkah. Untuk pengguna Jenkins, ide yang sama dijelaskan dalam mengintegrasikan tes otomatis Apidog dengan Jenkins.

Jadi, mana yang menang di CI?

Tidak ada pemenang tunggal, karena jawaban yang tepat tergantung pada di mana tes Anda sudah ada dan bagaimana tim Anda ingin menulis dan menyimpannya.

Apidog CLI menang ketika Anda menghargai penulisan visual dan satu sumber kebenaran lebih dari riwayat cloud yang dihosting. Anda membuat skenario sekali di editor visual, dengan perantaian permintaan dan pernyataan yang ditangani untuk Anda, dan skenario yang sama berjalan di CI berdasarkan referensi. Anda memutuskan apakah laporan tetap lokal atau diunggah. Dan karena Apidog mencakup desain, mocking, dan dokumentasi di ruang kerja yang sama, skenario tes berada di samping kontrak API yang diperiksanya, yang menjaga tes dan spesifikasi agar tidak terpisah. Tim yang mempertimbangkan platform secara lebih luas dapat membaca perbandingan Apidog vs Postman secara lengkap.

Postman CLI menang ketika tim Anda sudah menggunakan Postman. Koleksi Anda ada di sana, lingkungan Anda ada di sana, dan Anda menginginkan riwayat eksekusi di cloud Postman tanpa perlu menyiapkan apa pun. Perjalanan pulang-pergi cloud pada setiap eksekusi adalah kenyamanan nyata untuk pengaturan tersebut, dan alat ini secara resmi ditandatangani dan didukung. Jika itu menggambarkan tim Anda, beralih runner tidak banyak membantu Anda.

Jika Anda sudah merasa terbatasi oleh model cloud Postman, atau Anda hanya ingin menulis tes sekali dan menjalankannya di mana saja, langkahnya jelas. Unduh Apidog, buat skenario, buka tab CI/CD-nya, dan salin perintah `apidog run` yang dihasilkan ke pipeline Anda. Itu adalah seluruh pengaturannya.

tombol

FAQ

Apakah Postman CLI sama dengan Newman? Tidak. Newman adalah runner npm open-source yang lebih tua. Postman CLI adalah alat yang lebih baru yang dibangun di atas fondasi Newman, ditandatangani dan didukung oleh Postman, dengan pelaporan bawaan ke cloud Postman. Jika Anda memilih antara keduanya di sisi Postman, Postman CLI vs Newman menguraikan perbedaannya.

Apakah saya memerlukan akun atau token untuk kedua CLI di CI? Ya, untuk keduanya, tetapi bentuknya berbeda. Postman CLI mengautentikasi dengan kunci API Postman melalui `postman login --with-api-key`. Apidog CLI mengautentikasi dengan token akses yang dilewatkan sebagai `--access-token`. Simpan salah satu sebagai rahasia CI, jangan pernah di file alur kerja.

Apakah kedua runner menggagalkan build ketika tes gagal? Ya. Keduanya keluar dengan kode status non-nol pada tes atau pernyataan yang gagal, itulah yang memberi tahu sistem CI Anda untuk menandai build sebagai merah dan memblokir merge. Postman CLI menggunakan `--bail` untuk berhenti pada kegagalan pertama; Apidog CLI menggunakan `--on-error end`, yang merupakan default-nya.

Bisakah saya menyimpan laporan secara lokal daripada mengirimnya ke cloud? Apidog CLI menyimpan laporan secara lokal secara default dan menuliskannya ke `--out-dir`; Anda hanya mengunggah dengan `--upload-report`. Postman CLI juga menulis pelapor lokal, tetapi ketika Anda masuk, ia juga mengirimkan hasil eksekusi ke cloud Postman secara otomatis.

Bagaimana cara mendapatkan perintah eksekusi Apidog yang tepat untuk skenario saya? Buka skenario tes di Apidog, beralih ke tab CI/CD-nya, buat token akses, dan Apidog akan membangun perintah `apidog run` lengkap dengan ID skenario dan ID lingkungan sudah terisi. Salin, pindahkan token ke rahasia CI, dan Anda selesai. Untuk setiap flag yang tersedia, jalankan `apidog run --help`.

Mana yang harus dipilih oleh tim yang bermigrasi dari cloud Postman? Jika alasan Anda pergi adalah model atau harga yang berpusat pada cloud, Apidog CLI cocok, karena ia menjalankan satu skenario visual dari proyek Anda dan memungkinkan Anda memutuskan apa yang meninggalkan runner. Mulailah dengan perbandingan Apidog vs Postman untuk melihat bagaimana platform selaras di luar runner.