Apidog CLI vs Newman: Menjalankan Pengujian API di CI (2026)

Tes API Anda berhasil di laptop Anda. Pertanyaan yang lebih sulit adalah apakah tes tersebut berjalan pada setiap pull request, setiap merge, dan setiap nightly build tanpa campur tangan manusia. Tugas itu milik command-line runner. Ini mengambil tes yang sudah Anda tulis, menjalankannya secara headless di dalam pipeline Anda, keluar dengan kode status yang dapat dibaca oleh CI Anda, dan menulis laporan yang dapat diuraikan oleh dashboard Anda. Tanpa GUI, tanpa langkah manual, tanpa alasan untuk melewatkan eksekusi.

Selama bertahun-tahun, jawaban default untuk kebutuhan tersebut adalah Newman, command-line collection runner sumber terbuka milik Postman. Ini adalah alat yang solid dan dipahami dengan baik, dan banyak tim masih menggunakannya terlebih dahulu. Tetapi jika Anda membuat tes Anda di Apidog daripada Postman, Anda memiliki opsi kedua: Apidog CLI, yang menjalankan skenario tes yang sama yang Anda buat secara visual di aplikasi, secara headless di CI. Artikel ini adalah perbandingan jujur tingkat perintah antara keduanya. Ini mencakup apa yang Newman lakukan dengan baik, di mana Apidog CLI cocok, dan bagaimana rasanya masing-masing setelah terhubung ke pipeline yang sebenarnya.

tombol

TL;DR

• Newman (newman, diinstal melalui npm install -g newman) menjalankan file JSON koleksi Postman yang diekspor. Ini adalah sumber terbuka, gratis, dan membaca koleksi ditambah file lingkungan dari disk atau URL. Ini mendukung lingkungan, file data, jumlah iterasi, dan pelapor JUnit/JSON/HTML, serta keluar dengan nilai bukan nol ketika tes gagal.
• Apidog CLI (apidog-cli, biner apidog) menjalankan skenario tes yang Anda rancang di aplikasi Apidog, diambil berdasarkan ID menggunakan token akses. Anda tidak mengekspor apa pun atau memelihara file JSON secara manual; skenario visual adalah tes, dan CLI menjalankannya persis seperti yang akan dilakukan aplikasi.
• Keduanya terhubung ke GitHub Actions, GitLab CI, Jenkins, dan apa pun yang menggunakan Node.js. Keduanya akan menyebabkan build gagal pada tes yang gagal. JUnit XML adalah yang terhubung ke dashboard CI di kedua sisi.
• Pilih Newman ketika tes Anda sudah ada sebagai koleksi Postman dan Anda menginginkan runner gratis yang ramah repo tanpa akun baru.
• Pilih Apidog CLI ketika Anda menginginkan penulisan visual, permintaan berantai, manajemen lingkungan, dan eksekusi berbasis data yang tetap sinkron dengan skenario yang sama yang tim Anda debug setiap hari.

Masalah sebenarnya: tes yang ada tetapi tidak pernah dijalankan

Tes yang Anda jalankan secara manual adalah tes yang akan usang. Seseorang membuatnya, berhasil sekali, dan kemudian dibiarkan begitu saja sementara API berubah di bawahnya. Lebih banyak tes tidak akan memperbaikinya. Tes yang berjalan secara otomatis pada setiap perubahan akan memperbaikinya, karena mereka menghasilkan sinyal lulus atau gagal yang dapat ditindaklanjuti oleh pipeline Anda.

Runner CLI menutup celah tersebut. Agar berguna dalam CI, ia harus melakukan tiga hal: berjalan tanpa GUI, keluar dengan nilai bukan nol ketika sesuatu gagal sehingga build menjadi merah, dan menulis laporan yang dapat dibaca mesin sehingga peninjau dapat melihat apa yang rusak. Newman dan Apidog CLI keduanya melewati batas itu dengan bersih. Perbedaan mereka terletak di hulu perintah run, dalam bagaimana tes ditulis dan di mana ia berada. Jika Anda mengatur CI dari awal, pola yang lebih luas dalam cara mengotomatiskan tes API di CI/CD sangat cocok dengan perbandingan ini. Di sini kami tetap berfokus pada kedua runner tersebut.

Apa yang Newman lakukan dengan baik

Newman telah mendapatkan tempatnya. Ini adalah pendamping sumber terbuka resmi untuk Postman, dan bagi tim yang tesnya sudah ada sebagai koleksi Postman, ini adalah jalur paling langsung dari “tes di mesin saya” ke “tes di CI.” Penting untuk menyatakan kekuatannya dengan jelas sebelum perbandingan apa pun.

Ini gratis dan sumber terbuka. Anda menginstalnya dari npm dan menjalankannya di mana pun Node.js berjalan, tanpa lisensi terpisah untuk runner itu sendiri. Koleksi Anda adalah file JSON portabel yang dapat Anda masukkan ke repo, simpan sebagai artefak build, atau ambil dari URL. Portabilitas itu nyata, dan itu berarti Newman dapat masuk ke hampir semua pipeline tanpa hambatan.

Ini menggunakan kembali apa yang sudah Anda bangun. Jika tim Anda menulis permintaan, skrip pra-permintaan, dan pernyataan tes di Postman, Newman menjalankan koleksi yang sama tanpa perubahan. Tidak ada penulisan ulang. Skrip yang Anda tulis di editor Postman dieksekusi dengan cara yang sama dalam eksekusi headless, yang menjaga kurva pembelajaran tetap datar untuk pengguna Postman.

npm install -g newman

Biner adalah newman. Anda menjalankan koleksi yang diekspor dengan menunjuknya ke file JSON, biasanya dengan file lingkungan di sampingnya:

newman run api-tests.postman_collection.json -e staging.postman_environment.json

Itu adalah loop intinya. Ekspor koleksi dari Postman, commit JSON, dan jalankan. Newman membaca permintaan dan pernyataan dari file dan mengeksekusinya secara berurutan. Untuk jalur pengaturan lengkap, panduan Apidog sendiri tentang cara menginstal Newman dan menjalankan koleksi Postman mencakup alur ekspor-dan-jalankan langkah demi langkah.

Newman juga mendukung esensi CI yang Anda harapkan. Eksekusi berbasis data berasal dari file CSV atau JSON:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -d users.csv \
  -n 5

Di sini -d menyediakan file data dan -n mengatur jumlah iterasi, sehingga koleksi berjalan sekali per baris atau sejumlah tetap kali. Ini adalah primitif yang sama yang dibutuhkan setiap runner serius, dan Newman telah memilikinya selama bertahun-tahun.

Di mana Newman mulai merugikan Anda

Kekuatan di atas jujur, tetapi begitu juga dengan trade-off, dan itu muncul dalam pemeliharaan sehari-hari daripada dalam satu perintah pun.

Yang terbesar adalah langkah ekspor. Koleksi Postman di CI adalah snapshot. Anda membuat dan melakukan debug di aplikasi Postman, lalu mengekspor file JSON untuk dijalankan secara headless. Saat seseorang mengedit permintaan di aplikasi dan lupa mengekspor ulang, koleksi yang Anda commit akan menyimpang dari sumber kebenaran. Eksekusi CI terus lulus terhadap definisi lama sementara API yang sebenarnya telah berubah. Tidak ada dalam tooling yang memaksa keduanya kembali sinkron; itu tergantung pada siapa pun yang ingat untuk mengekspor.

Skrip adalah hal lainnya. Logika tes Postman berada dalam cuplikan JavaScript yang melekat pada setiap permintaan, dan skrip itulah tempat terjadinya perantaian, ekstraksi variabel, dan pernyataan. Itu fleksibel, tetapi itu berarti rangkaian tes Anda adalah tumpukan skrip kecil untuk ditulis, didebug, dan dipelihara secara manual. Seiring bertambahnya skenario, begitu pula permukaan skrip yang Anda miliki. Ini adalah bagian dari pola yang lebih luas yang dihadapi tim saat koleksi berskala, yang kami bahas dalam batasan Postman Collection Runner dan cara mengatasinya.

Tidak ada satu pun dari ini yang menjadikan Newman alat yang buruk. Ini menjadikannya runner yang ergonominya terikat pada model penulisan Postman: skrip ditambah langkah ekspor. Jika model itu cocok dengan tim Anda, Newman baik-baik saja. Jika proses ekspor-dan-sinkronisasi adalah bagian yang terus-menerus bermasalah, di situlah runner yang berbeda sangat membantu.

Apa yang Apidog CLI lakukan secara berbeda

Apidog mengambil jalur yang berbeda ke pipeline yang sama. Anda membuat tes secara visual di aplikasi Apidog. Anda merangkai permintaan menjadi skenario tes, menambahkan pernyataan di editor tanpa kode, menarik nilai dari satu respons ke permintaan berikutnya, dan mengulang seluruhnya di atas file data. CLI adalah eksekutor headless untuk skenario tersebut. Ini tidak memiliki format file terpisah dan tidak ada yang perlu diekspor. Ini mengambil skenario yang Anda beri nama berdasarkan ID dari proyek Apidog Anda dan menjalankannya persis seperti yang akan dilakukan aplikasi.

Itu menghilangkan masalah penyimpangan. Skenario dalam proyek adalah tes. Tidak ada snapshot yang diekspor yang dapat keluar dari sinkronisasi, karena CLI menjalankan skenario langsung, bukan salinannya. Anda membuatnya sekali dalam pembangun visual yang menangani perantaian permintaan dan pernyataan untuk Anda, kemudian skenario yang sama berjalan di CI. Loop penulisan cepat dan loop otomatisasi berbagi satu sumber kebenaran.

npm install -g apidog-cli

Biner adalah apidog. Sebuah eksekusi tipikal menamai skenario berdasarkan ID, memilih lingkungan, 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, buat token akses, dan Apidog akan membuat perintah lengkap untuk Anda dengan ID skenario dan ID lingkungan sudah terisi. Anda menyalinnya sekali, lalu memindahkan token ke rahasia CI dan mereferensikannya sebagai `$APIDOG_ACCESS_TOKEN`. Jika Anda tidak yakin flag mana yang didukung oleh versi yang Anda instal, jalankan `apidog run --help` dan itu akan mencetak opsi yang tersedia secara tepat.

Model berbasis token, pengambilan berdasarkan ID adalah perbedaan paling jelas dari Newman. Newman membaca file koleksi dari disk; Apidog CLI menjangkau proyek melalui jaringan, diautentikasi, dan menjalankan skenario yang tersimpan di sana. Keduanya tidak salah. Keduanya cocok untuk pengaturan tim yang berbeda, dan pilihan sebagian besar adalah apakah Anda ingin tes itu hidup sebagai file yang diekspor atau sebagai skenario langsung di ruang kerja bersama.

Perbandingan

Dua hal menonjol. Pertama, kedua runner mencakup esensi CI yang sama: pemilihan lingkungan, iterasi berbasis data, format laporan yang penting, dan keluar dengan nilai bukan nol saat gagal. Nama-nama flag bahkan cukup mirip sehingga memori otot dapat ditransfer (`-e`, `-d`, `-n`, `-r`). Kedua, perbedaan sebenarnya bukanlah kemampuan mentah. Ini adalah di mana tes berada dan bagaimana Anda menulisnya. Newman menjalankan koleksi yang diekspor yang dibuat dengan skrip. Apidog menjalankan skenario visual langsung dengan referensi. Versi yang lebih mendalam dari perbandingan ini, yang dibingkai di sekitar dua runner dunia Postman, ada di Postman CLI vs Newman jika Anda juga menginginkan sudut pandang itu.

Pelapor dan kode keluar: bagian-bagian yang sebenarnya dibaca oleh CI

Sebuah runner mendapatkan tempatnya di pipeline melalui dua perilaku: laporan yang ditulisnya dan kode keluar yang dikembalikannya. Jika ini benar, sisanya hanyalah pengaturan.

Newman memilih pelapor dengan flag `-r` dan daftar yang dipisahkan koma. JUnit dan JSON sudah termasuk; pelapor HTML adalah add-on yang paling umum:

newman run api-tests.postman_collection.json \
  -e staging.postman_environment.json \
  -r cli,junit \
  --reporter-junit-export ./results/junit.xml

JUnit XML adalah apa yang diuraikan oleh dashboard CI Anda menjadi pohon lulus atau gagal. Flag `--bail` Newman menghentikan eksekusi setelah kegagalan pertama, yang menjaga umpan balik tetap cepat pada smoke test. Tanpanya, eksekusi selesai dan melaporkan setiap kegagalan sekaligus.

Apidog CLI menggunakan flag `-r` yang sama yang dipisahkan koma 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 di 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. Bagaimanapun, eksekusi berakhir dengan nilai bukan nol jika ada sesuatu yang gagal.

Kontrak kode keluar sama di kedua sisi, dan itu adalah bagian yang menopang beban. Ketika suatu pernyataan gagal, runner keluar dengan nilai bukan nol. CI membaca kode itu, menandai langkah sebagai gagal, membuat job gagal, dan memblokir merge atau deploy. Anda tidak mengonfigurasi apa pun tambahan. Satu jebakan, yang sama untuk keduanya, adalah menelan kode keluar: bungkus eksekusi dalam pipeline shell atau tambahkan `|| true` dan kode keluar bukan nol akan hilang, sehingga gerbang diam-diam berhenti berfungsi. Jangan lakukan itu. Untuk konteks yang lebih luas tentang format laporan, pengujian API berbasis data dengan CSV atau JSON menunjukkan bagaimana laporan terhubung kembali ke data iterasi.

Newman di GitHub Actions

Karena koleksinya adalah file yang diekspor di repo, alur kerjanya singkat. Checkout kodenya, instal Newman, jalankan koleksinya, unggah laporan bahkan saat terjadi kegagalan.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Newman
        run: npm install -g newman

      - name: Run API tests
        run: |
          newman run ./tests/api-tests.postman_collection.json \
            -e ./tests/staging.postman_environment.json \
            -r cli,junit \
            --reporter-junit-export ./results/junit.xml

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: ./results

Tidak diperlukan rahasia jika file koleksi dan lingkungan di-commit ke repo. Baris `if: always()` menjaga unggahan laporan tetap berjalan bahkan ketika tes gagal, yang justru saat Anda ingin membacanya. Biaya yang Anda tanggung adalah langkah ekspor yang menghasilkan file JSON tersebut sejak awal, dan mengingat untuk menyegarkannya ketika API berubah.

Apidog CLI di GitHub Actions

Alur kerja Apidog memiliki bentuk yang sama, dengan satu perubahan: token akses berasal dari rahasia repositori, dan Anda memilih skenario berdasarkan ID alih-alih menunjuk ke file.

name: API tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API test scenario
        run: |
          apidog run \
            --access-token "$APIDOG_ACCESS_TOKEN" \
            -t 605067 \
            -e 1629989 \
            -r html,junit \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Perhatikan simetrinya. Checkout yang sama, setup Node yang sama, bentuk instal-lalu-jalankan yang sama, unggah selalu yang sama. Satu-satunya perbedaan nyata adalah token yang dihubungkan sebagai rahasia dan skenario yang dipilih berdasarkan ID daripada berdasarkan jalur file. Karena skenario diambil secara langsung, tidak ada file JSON yang harus selalu diperbarui. Untuk pola yang sama di sistem lain, cara mengotomatiskan tes API di GitHub Actions membawa struktur yang sama ke GitLab CI dan Jenkins.

Cara memilih

Keputusan jarang bergantung pada runner mana yang secara objektif lebih baik. Ini bergantung pada di mana tes Anda sudah ada dan bagaimana tim Anda ingin memeliharanya.

Pilih Newman ketika tes Anda sudah berupa koleksi Postman. Jika suite Anda berada di Postman, tim Anda menulis skrip tes di editor, dan Anda menginginkan runner gratis, sumber terbuka yang dapat diintegrasikan ke pipeline mana pun tanpa akun baru, Newman adalah pilihan yang tepat. Ini adalah pilihan alami untuk pengguna Postman yang nyaman mengekspor koleksi dan meng-commit JSON, dan yang tidak keberatan memiliki skrip tes secara manual. Anda dapat membaca lebih lanjut tentang perbedaan dalam ekosistem Postman di apa perbedaan antara Newman dan Postman.

Pilih Apidog CLI ketika kecepatan penulisan dan satu sumber kebenaran lebih penting daripada tetap berada di dalam Postman. Jika Anda lebih suka membangun skenario tes secara visual, merangkai permintaan, mengekstraksi variabel, dan menjalankan skenario yang sama di berbagai lingkungan tanpa menulis dan mengekspor ulang kode tes, Apidog menghilangkan hambatan itu. Rancang, debug, mock, dan uji secara langsung dalam satu ruang kerja, dan CLI menjalankan skenario persis yang Anda bangun. Untuk tim yang beralih dari Postman, migrasi adalah sesuatu yang dicakup Apidog sebagai alternatif Postman untuk pengujian API, dan impornya adalah satu klik.

Ada juga jawaban untuk kedua alat tersebut. Beberapa tim mempertahankan langkah Newman yang ada yang menjalankan koleksi lama mereka sementara mereka memindahkan skenario berantai baru yang lebih kompleks ke Apidog. Kedua CLI dapat hidup berdampingan dengan baik dalam satu pipeline; keduanya adalah langkah terpisah dengan kode keluar terpisah, dan Anda dapat menghentikan langkah Newman sesuai jadwal Anda sendiri.

Untuk menyiapkan skenario otomatis pertama Anda dan menjalankannya dari terminal pada sore yang sama, unduh Apidog, buat skenario tes, dan salin perintah yang dihasilkan dari tab CI/CD-nya.

tombol