Apidog CLI ve Newman Karşılaştırması: CI'da API Testlerini Çalıştırma (2026)

API testleriniz dizüstü bilgisayarınızda geçiyor. Daha zor olan soru ise, herhangi bir insanın tıklamasına gerek kalmadan her çekme isteğinde, her birleştirmede ve her gece yapısında çalışıp çalışmadıklarıdır. Bu görev bir komut satırı çalıştırıcısına aittir. Zaten yazdığınız testleri alır, işlem hattınız içinde başsız bir şekilde yürütür, CI'nizin okuyabileceği bir durum koduyla çıkar ve gösterge tablonuzun ayrıştırabileceği bir rapor yazar. GUI yok, manuel adım yok, çalıştırmayı atlamak için hiçbir bahane yok.

Yıllardır bu ihtiyaca varsayılan yanıt, Postman'in açık kaynaklı komut satırı koleksiyon çalıştırıcısı olan Newman olmuştur. Sağlam, iyi anlaşılmış bir araçtır ve birçok ekip hala önce ona başvurur. Ancak testlerinizi Postman yerine Apidog'da yazıyorsanız, ikinci bir seçeneğiniz var: Apidog CLI, uygulamada görsel olarak oluşturduğunuz aynı test senaryolarını CI'da başsız bir şekilde çalıştırır. Bu makale, ikisinin dürüst, komut düzeyinde bir karşılaştırmasıdır. Newman'ın iyi yaptığı şeyleri, Apidog CLI'ın nereye uyduğunu ve her birinin gerçek bir işlem hattına bağlandığında nasıl hissettirdiğini kapsar.

TL;DR

• Newman (newman, npm install -g newman ile yüklenir) dışa aktarılmış bir Postman koleksiyon JSON dosyasını çalıştırır. Açık kaynaklı, ücretsizdir ve bir koleksiyonu ile ortam dosyasını diskten veya bir URL'den okur. Ortamları, veri dosyalarını, yineleme sayılarını ve JUnit/JSON/HTML raporlayıcıları destekler ve bir test başarısız olduğunda sıfır olmayan bir durum koduyla çıkar.
• Apidog CLI (apidog-cli, ikili dosya apidog) Apidog uygulamasında tasarladığınız test senaryolarını, bir erişim belirteci kullanarak ID ile getirerek çalıştırır. Hiçbir şeyi dışa aktarmazsınız veya JSON dosyasını manuel olarak yönetmezsiniz; görsel senaryo testin kendisidir ve CLI onu tıpkı uygulamanın yapacağı gibi çalıştırır.
• Her ikisi de GitHub Actions, GitLab CI, Jenkins ve Node.js içeren herhangi bir şeye entegre olur. Her ikisi de başarısız bir testte derlemeyi durdurur. JUnit XML, her iki taraftaki CI panolarına bağlanan şeydir.
• Testleriniz zaten Postman koleksiyonları olarak mevcutsa ve yeni bir hesap gerektirmeyen, ücretsiz, depo dostu bir çalıştırıcı istiyorsanız Newman'ı seçin.
• Görsel yazarlık, istek zincirleme, ortam yönetimi ve ekibinizin her gün hata ayıklama yaptığı aynı senaryo ile senkronize kalan veri odaklı çalıştırmalar istiyorsanız Apidog CLI'yı seçin.

Gerçek sorun: var olan ama hiç çalışmayan testler

Elle çalıştırdığınız bir test, çürüyen bir testtir. Birisi onu inşa etti, bir kez geçti ve sonra API altında sürüklenirken dokunulmadan kaldı. Daha fazla test bunu düzeltmez. Her değişiklikte otomatik olarak çalışan testler düzeltir, çünkü işlem hattınızın üzerinde hareket edebileceği bir geçiş veya başarısızlık sinyali üretirler.

Bir CLI çalıştırıcısı bu boşluğu kapatır. CI'da faydalı olmak için üç şey yapması gerekir: GUI olmadan çalışmak, bir şey başarısız olduğunda derlemenin kırmızıya dönmesi için sıfır olmayan bir değerle çıkmak ve gözden geçirenlerin neyin bozulduğunu görebilmesi için makine tarafından okunabilir bir rapor yazmak. Newman ve Apidog CLI, bu barı temiz bir şekilde aşar. Farklılaştıkları yer, çalıştırma komutunun yukarısında, testin nasıl yazıldığı ve nerede yaşadığıdır. CI'yi sıfırdan kuruyorsanız, CI/CD'de API testlerini otomatikleştirme başlıklı makaledeki daha geniş kalıplar bu karşılaştırmayla iyi eşleşir. Burada iki çalıştırıcıya odaklanıyoruz.

Newman neyi iyi yapar

Newman yerini hak etmiştir. Postman'in resmi açık kaynaklı eşlikçisidir ve testleri zaten Postman koleksiyonları olarak bulunan ekipler için, "makinemdeki testler"den "CI'daki testler"e giden en doğrudan yoldur. Herhangi bir karşılaştırmadan önce güçlü yönlerini açıkça belirtmekte fayda var.

Ücretsiz ve açık kaynaklıdır. npm'den yüklersiniz ve Node.js'nin çalıştığı her yerde, çalıştırıcının kendisi için ayrı bir lisansa gerek kalmadan çalıştırırsınız. Koleksiyonunuz, bir depoya gönderebileceğiniz, bir yapı yapıtı olarak saklayabileceğiniz veya bir URL'den getirebileceğiniz taşınabilir bir JSON dosyasıdır. Bu taşınabilirlik gerçektir ve Newman'ın neredeyse her işlem hattına sorunsuz bir şekilde entegre olabileceği anlamına gelir.

Zaten oluşturduklarınızı yeniden kullanır. Ekibiniz Postman'de istekleri, ön istek betiklerini ve test onaylamalarını yazıyorsa, Newman bu koleksiyonları değişmeden çalıştırır. Yeniden yazma yoktur. Postman düzenleyicisinde yazdığınız betikler, başsız çalıştırmada aynı şekilde yürütülür, bu da Postman kullanıcıları için öğrenme eğrisini düz tutar.

Yüklemesi tek bir komuttur:

npm install -g newman

İkili dosya newman'dir. Dışa aktarılmış bir koleksiyonu, genellikle yanında bir ortam dosyasıyla birlikte JSON dosyasına işaret ederek çalıştırırsınız:

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

Bu, temel döngüdür. Koleksiyonu Postman'den dışa aktarın, JSON'ı kaydedin ve çalıştırın. Newman istekleri ve onaylamaları dosyadan okur ve sırayla yürütür. Tam kurulum yolu için, Apidog'un Newman nasıl kurulur ve Postman koleksiyonları nasıl çalıştırılır hakkındaki kendi kılavuzu, dışa aktarma ve çalıştırma akışını adım adım kapsar.

Newman ayrıca beklediğiniz CI temellerini de destekler. Veri odaklı çalıştırmalar bir CSV veya JSON dosyasından gelir:

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

Burada -d veri dosyasını sağlar ve -n yineleme sayısını ayarlar, böylece koleksiyon her satır için bir kez veya belirli sayıda çalışır. Bunlar, herhangi bir ciddi çalıştırıcının ihtiyaç duyduğu aynı temel öğelerdir ve Newman yıllardır bunlara sahiptir.

Newman'ın size maliyet çıkarmaya başladığı yer

Yukarıdaki güçlü yönler dürüsttür, ancak ödünleşimler de öyledir ve bunlar herhangi bir tek komutta değil, günlük bakımda ortaya çıkar.

En büyüğü, dışa aktarma adımıdır. CI'daki bir Postman koleksiyonu bir anlık görüntüdür. Postman uygulamasında yazar ve hata ayıklarsınız, ardından başsız çalıştırmak için bir JSON dosyası dışa aktarırsınız. Birisi uygulamada bir isteği düzenleyip yeniden dışa aktarmayı unuttuğu anda, taahhüt ettiğiniz koleksiyon doğruluk kaynağından sapar. Gerçek API ilerlerken, CI çalıştırması eski bir tanıma karşı geçmeye devam eder. Araçlardaki hiçbir şey ikisini tekrar senkronize etmeye zorlamaz; bu, kimin dışa aktarmayı hatırladığına bağlıdır.

Diğeri ise betik yazmadır. Postman test mantığı, her isteğe eklenmiş JavaScript kod parçacıklarında yaşar ve zincirleme, değişken çıkarma ve onaylamalar bu betiklerde gerçekleşir. Bu esnektir, ancak test süitinizin elle yazılması, hata ayıklanması ve bakımı gereken küçük betik yığınları olduğu anlamına gelir. Senaryolar büyüdükçe, sahip olduğunuz betik yüzeyi de büyür. Bu, koleksiyonlar ölçeklendikçe ekiplerin karşılaştığı daha geniş bir kalıbın parçasıdır ve Postman Collection Runner kısıtlamaları ve bunlarla nasıl başa çıkılacağı başlıklı yazımızda buna değiniyoruz.

Bunların hiçbiri Newman'ı kötü bir araç yapmaz. Onu, ergonomisi Postman'in yazım modeline bağlı bir çalıştırıcı yapar: betikler artı bir dışa aktarma adımı. Bu model ekibinize uyuyorsa, Newman iyidir. Eğer dışa aktarma ve senkronizasyon dansı sürekli bozulan kısımsa, farklı bir çalıştırıcının yardımcı olacağı yer tam da burasıdır.

Apidog CLI'ın farklı yaptığı şeyler

Apidog, aynı işlem hattına farklı bir yol izler. Testleri Apidog uygulamasında görsel olarak oluşturursunuz. İstekleri bir test senaryosuna zincirlersiniz, kodsuz bir düzenleyicide onaylamalar eklersiniz, bir yanıttan bir değeri sonraki isteğe çekersiniz ve tümünü bir veri dosyası üzerinde döngüye alırsınız. CLI, bu senaryolar için başsız yürütücüdür. Ayrı bir dosya formatı yoktur ve dışa aktarılacak hiçbir şey yoktur. Adını ID ile verdiğiniz senaryoyu Apidog projenizden getirir ve tıpkı uygulamanın yapacağı gibi çalıştırır.

Bu, sapma sorununu ortadan kaldırır. Projedeki senaryo testin kendisidir. Senkronizasyon dışı kalacak dışa aktarılmış bir anlık görüntü yoktur, çünkü CLI canlı senaryoyu çalıştırır, bir kopyasını değil. İstek zincirlemeyi ve onaylamaları sizin için halleden görsel bir oluşturucuda bir kez yazarsınız, sonra aynı senaryo CI'da çalışır. Hızlı yazma döngüsü ve otomasyon döngüsü tek bir doğruluk kaynağını paylaşır.

Yüklemesi tek bir npm komutudur:

npm install -g apidog-cli

İkili dosya apidog'dur. Tipik bir çalıştırma, bir senaryoyu ID ile adlandırır, bir ortam seçer ve bir erişim belirteci ile kimlik doğrulaması yapar:

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

Bu ID'leri elle yazmazsınız. Apidog'da test senaryosunu açın, CI/CD sekmesine geçin, bir erişim belirteci oluşturun ve Apidog, senaryo ID'si ve ortam ID'si zaten doldurulmuş olarak sizin için tam komutu oluşturur. Bir kez kopyalarsınız, ardından belirteci bir CI sırrına taşırsınız ve $APIDOG_ACCESS_TOKEN olarak referans verirsiniz. Yüklü sürümünüzün hangi bayrakları desteklediğinden emin değilseniz, apidog run --help komutunu çalıştırın ve mevcut seçenekleri yazdıracaktır.

Belirteç tabanlı, ID ile getirme modeli Newman'dan en açık farktır. Newman diskten bir koleksiyon dosyasını okur; Apidog CLI ise ağ üzerinden bir projeye erişir, kimlik doğrulaması yapar ve orada depolanan senaryoyu çalıştırır. İkisi de yanlış değildir. Farklı ekip kurulumlarına uygundurlar ve seçim çoğunlukla testin dışa aktarılmış bir dosya olarak mı yoksa paylaşılan bir çalışma alanında canlı bir senaryo olarak mı yaşamasını istediğinizle ilgilidir.

Yan yana karşılaştırma

İki şey öne çıkıyor. Birincisi, her iki çalıştırıcı da aynı CI temel öğelerini kapsar: ortam seçimi, veri odaklı yineleme, önemli rapor formatları ve başarısızlıkta sıfır olmayan bir çıkış. Bayrak adları bile kas hafızasının aktarımına izin verecek kadar yakındır (-e, -d, -n, -r). İkincisi, gerçek ayrım ham yetenek değildir. Testin nerede yaşadığı ve onu nasıl yazdığınızdır. Newman, betiklerle yazılmış dışa aktarılmış bir koleksiyonu çalıştırır. Apidog, canlı bir görsel senaryoyu referans alarak çalıştırır. Bu karşılaştırmanın, Postman dünyasının iki çalıştırıcısı etrafında çerçevelenmiş daha derin versiyonu, o açıyı da isterseniz Postman CLI vs Newman makalesinde bulunmaktadır.

Raporlayıcılar ve çıkış kodları: CI'nın aslında okuduğu kısımlar

Bir çalıştırıcı, işlem hattındaki yerini iki davranışla kazanır: yazdığı rapor ve döndürdüğü çıkış kodu. Bunları doğru yapın, gerisi bağlantıdır.

Newman, raporlayıcıları -r bayrağı ve virgülle ayrılmış bir liste ile seçer. JUnit ve JSON kutudan çıkar; HTML raporlayıcı en yaygın eklentidir:

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

JUnit XML, CI gösterge tablonuzun bir geçiş veya başarısızlık ağacına ayrıştırdığı şeydir. Newman'ın --bail bayrağı, ilk başarısızlıktan sonra çalıştırmayı durdurarak hızlı geri bildirim sağlar. Bu bayrak olmadan, çalıştırma tamamlanır ve her başarısızlığı bir kerede raporlar.

Apidog CLI, aynı virgülle ayrılmış -r bayrağını kullanır ve her şeyi tek bir çıktı dizinine yazar:

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

--on-error bayrağı, senaryo içi davranışını şekillendirir: end ilk başarısızlıkta durur ve varsayılandır, continue her adımı çalıştırarak tüm başarısızlıkları tek bir raporda toplamanızı sağlar ve ignore bilinen kararsız bir adımı atlar. Her iki durumda da, bir şey başarısız olursa çalıştırma sıfır olmayan bir değerle biter.

Çıkış kodu sözleşmesi her iki tarafta da aynıdır ve yük taşıyan kısımdır. Bir onaylama başarısız olduğunda, çalıştırıcı sıfır olmayan bir değerle çıkar. CI bu kodu okur, adımı başarısız olarak işaretler, işi başarısız kılar ve birleştirmeyi veya dağıtımı engeller. Ek bir şey yapılandırmazsınız. Her ikisi için de aynı olan tek tuzak, çıkış kodunu yutmaktır: çalıştırmayı bir kabuk ardışık düzenine sarmak veya || true eklemek, sıfır olmayan çıkışın yutulmasına neden olur, böylece geçit sessizce çalışmayı durdurur. Bunu yapmayın. Rapor formatları hakkında daha geniş bir bağlam için, CSV veya JSON ile veri odaklı API testi raporun yineleme verilerine nasıl bağlandığını gösterir.

GitHub Actions'ta Newman

Koleksiyon depoda dışa aktarılmış bir dosya olduğu için iş akışı kısadır. Kodu çekin, Newman'ı kurun, koleksiyonu çalıştırın, raporu başarısızlık durumunda bile yükleyin.

name: API testleri

on:
  pull_request:
    branches: [main]

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

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

      - name: Newman'ı Yükle
        run: npm install -g newman

      - name: API testlerini çalıştır
        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: Raporu yükle
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: ./results

Koleksiyon ve ortam dosyaları depoya kaydedilmişse hiçbir sırra gerek yoktur. if: always() satırı, testler başarısız olduğunda bile rapor yüklemesini çalışır durumda tutar ki bu, tam olarak okumak istediğiniz zamandır. Kabul ettiğiniz maliyet, bu JSON dosyalarını ilk etapta üreten dışa aktırma adımı ve API değiştiğinde bunları yenilemeyi hatırlamaktır.

GitHub Actions'ta Apidog CLI

Apidog iş akışı aynı şekildedir, tek bir değişiklikle: erişim belirteci depo sırlarından gelir ve senaryoyu bir dosyaya işaret etmek yerine ID ile seçersiniz.

name: API testleri

on:
  pull_request:
    branches: [main]

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

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

      - name: Apidog CLI'yı Yükle
        run: npm install -g apidog-cli

      - name: API test senaryosunu çalıştır
        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: Raporu yükle
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-report
          path: ./apidog-reports

Simetriye dikkat edin. Aynı kodu çekme, aynı Node kurulumu, aynı yükle-sonra-çalıştır şekli, aynı her zaman yükleme. Tek gerçek farklar, bir sır olarak bağlı olan belirteç ve senaryonun dosya yolu yerine ID ile seçilmesidir. Senaryo canlı olarak getirildiği için güncel tutulması gereken bir JSON dosyası yoktur. Diğer sistemlerdeki aynı kalıp için, GitHub Actions'ta API testleri nasıl otomatikleştirilir GitLab CI ve Jenkins'e yapıyı taşır.

Nasıl seçilir

Karar nadiren hangi çalıştırıcının nesnel olarak daha iyi olduğuna bağlıdır. Testlerinizin nerede yaşadığına ve ekibinizin bunları nasıl sürdürmek istediğine bağlıdır.

Testleriniz zaten Postman koleksiyonları olduğunda Newman'ı seçin. Test paketiniz Postman'de yaşıyorsa, ekibiniz test betiklerini düzenleyicide yazıyorsa ve yeni bir hesap gerektirmeyen, herhangi bir işlem hattına entegre olabilen ücretsiz, açık kaynaklı bir çalıştırıcı istiyorsanız, Newman doğrudan uygun olandır. Postman mağazaları için, bir koleksiyonu dışa aktarmaya ve JSON'ı kaydetmeye alışkın olanlar ve test betiklerini elle yönetmekten çekinmeyenler için doğal bir seçimdir. Postman ekosistemindeki farklar hakkında daha fazlasını Newman ve Postman arasındaki fark nedir makalesinde okuyabilirsiniz.

Yazma hızı ve tek bir doğruluk kaynağı, Postman içinde kalmaktan daha önemli olduğunda Apidog CLI'yı seçin. Bir test senaryosunu görsel olarak oluşturmayı, istekleri zincirlemeyi, değişkenleri çıkarmayı ve aynı senaryoyu test kodu yazıp yeniden dışa aktarmadan farklı ortamlarda çalıştırmayı tercih ediyorsanız, Apidog bu sürtünmeyi ortadan kaldırır. Tasarlayın, hata ayıklayın, alay edin ve test edin, hepsi tek bir çalışma alanında canlı olarak gerçekleşir ve CLI oluşturduğunuz senaryoyu aynen çalıştırır. Postman'den geçen ekipler için, geçiş, Apidog'un bir API testi için Postman alternatifi olarak ele aldığı bir konudur ve içe aktarma tek bir tıklamayla yapılır.

Her iki aracı da kullanma seçeneği de var. Bazı ekipler, yeni, daha karmaşık zincirlenmiş senaryoları Apidog'a taşırken, mevcut Newman adımını eski koleksiyonlarını çalıştırmak için kullanmaya devam eder. İki CLI, tek bir işlem hattında sorunsuz bir şekilde bir arada bulunabilir; bunlar ayrı çıkış kodlarına sahip ayrı adımlardır ve Newman adımını kendi zaman çizelgenize göre emekliye ayırabilirsiniz.

İlk otomatik senaryonuzu kurmak ve aynı öğleden sonra terminalden çalıştırmak için Apidog'u indirin, bir test senaryosu oluşturun ve CI/CD sekmesinden oluşturulan komutu kopyalayın.