Apidog CLI vs Postman CLI Karşılaştırması: Daha İyi CI Test Çalıştırıcısı

API testleriniz dizüstü bilgisayarınızda Çalıştır'a tıkladığınızda geçer. Bu hiçbir şeyi kanıtlamaz. Önemli olan test, her çekme isteğinde, her birleştirmede ve her gece derlemesinde, herhangi bir insan müdahalesi olmadan çalışan testtir. Testlerinizi bu döngüye sokma görevi bir komut satırı çalıştırıcısına aittir. Zaten yazdığınız testleri alır, bunları işlem hattınızın içinde başsız olarak çalıştırır, CI'nizin okuyabileceği bir durum koduyla çıkar ve derleme panosunda görünen bir rapor yazar.

Ekipler bunu kurarken sürekli olarak iki çalıştırıcıdan bahseder: Postman CLI ve Apidog CLI. Farklı başlangıç noktalarından aynı hedefi amaçlarlar. Postman CLI, Postman'da oluşturduğunuz koleksiyonları çalıştırır. Apidog CLI, Apidog'da görsel olarak oluşturduğunuz test senaryolarını çalıştırır. Her ikisi de tek adımda kurulur, her ikisi de GitHub Actions, GitLab CI ve Jenkins'e entegre olur ve bir test başarısız olduğunda her ikisi de derlemeyi kırmızıya çevirir. Gerçek farklılıklar çalıştırma komutunun öncesinde yatar: testleri nasıl yazdığınız, CI'da nasıl kimlik doğruladığınız ve test tanımının gerçekte nerede bulunduğu.

Özetle

• Postman CLI (postman ikili dosyası), Postman çalışma alanınızda depolanan koleksiyonları çalıştırır. Newman tabanlıdır, Postman tarafından imzalanmış ve desteklenir, Postman API anahtarı ile kimlik doğrulaması yapar. Oturum açtığınızda, çalıştırma sonuçlarını otomatik olarak Postman bulutuna geri gönderir.
• Apidog CLI (apidog-cli, apidog ikili dosyası), Apidog'da görsel olarak tasarladığınız test senaryolarını çalıştırır. Bir erişim belirteciyle bir senaryoyu kimliğine göre işaret edersiniz ve bu senaryoyu GUI olmadan başsız olarak yürütür.
• Her ikisi de JUnit, JSON, HTML ve terminal raporları üretir. Her ikisi de başarısız bir testte derlemeyi başarısız kılar. Her iki durumda da bir CI panosuna takılan JUnit XML'dir.
• Testleriniz zaten Postman koleksiyonlarında bulunuyorsa ve ekibiniz raporlama ve geçmiş için Postman bulutuna bağlıysa Postman CLI'ı seçin.
• Görsel senaryo yazımı, istek zincirleme, ortam yönetimi ve tek bir doğruluk kaynağından veri odaklı çalıştırmalar istiyorsanız, raporların yerel kalıp kalmayacağı veya buluta gidip gitmeyeceği üzerinde tam kontrolle Apidog CLI'ı seçin.

Gerçek sorun: var olan ama asla çalıştırılmayan testler

Elle çalıştırdığınız bir test, çürüyen bir testtir. Biri onu yazdı, bir kez geçti ve sonra API altında kaybolurken dokunulmadan kaldı. Üç ay sonra test yanlış çıktı ve kimse fark etmedi, çünkü kimse çalıştırmadı. Çözüm daha fazla test yazmak değil. Sahip olduğunuz testleri her değişiklikte otomatik olarak çalıştırmak, işlem hattının üzerinde hareket edebileceği bir geçiş veya başarısızlık sinyali ile sağlamaktır.

Bir CLI çalıştırıcısı, bu boşluğu kapatan araçtır. CI'da yer edinmek için üç şey yapması gerekir. Bir GUI olmadan çalışmalıdır, çünkü CI çalıştırıcınızın ekranı yoktur. Bir şeyler başarısız olduğunda sıfır olmayan bir değerle çıkmalıdır, böylece derleme kırmızıya döner ve bozuk bir birleştirme engellenir. Ve makine tarafından okunabilir bir rapor yazmalıdır, böylece inceleyen kişi hiçbir şeyi yerel olarak yeniden çalıştırmadan neyin bozuk olduğunu görür. Postman CLI ve Apidog CLI her ikisi de bu çıtayı temiz bir şekilde geçer. Ayrıldıkları nokta ise run öncesinde olan her şeydir: testin nasıl yazıldığı ve CI onu aradığında nerede yaşadığı.

Otomatik testleri sıfırdan kuruyorsanız, CI/CD'de API testlerini otomatikleştirme makalesindeki daha geniş kalıpları bu yazıyla birlikte okumaya değer. Burada, odak iki çalıştırıcı üzerinde kalır.

Postman CLI neyi iyi yapar

İlk olarak, birçok kişinin kafasını karıştıran bir açıklama: Postman CLI, Newman değildir. Newman, topluluğun yıllardır kullandığı eski, açık kaynaklı, npm tabanlı bir çalıştırıcıdır. Postman CLI ise Newman'ın temeli üzerine kurulmuş, ancak Postman şirketi tarafından imzalanmış ve resmi olarak desteklenen daha yeni bir araçtır. Eğer Newman kullanıyorsanız, ikisi birbirinin yerine geçemez ve fark CI'da önemlidir. Postman tarafındaki iki seçenek arasında karar veriyorsanız, bu ayrımı Postman CLI vs Newman makalesinde detaylı olarak ele aldık.

Postman CLI'ın en büyük gücü, ekibinizin zaten bildiği dünyanın içinde kalmasıdır. Koleksiyonlarınız, ortamlarınız ve paylaşılan değişkenleriniz zaten bir Postman çalışma alanında yaşıyorsa, CLI bunları neredeyse hiç çeviri yapmadan çalıştırır. Hiçbir şeyi yeniden inşa etmezsiniz. Kimlik doğrulaması yapar, koleksiyonu adlandırır ve istekleri ve testleri uygulamanın yapacağı gibi çalıştırır.

Kurulumu tek bir komuttur. macOS ve Linux'ta resmi kurulum betiğini çalıştırırsınız:

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

Windows'ta imzalı PowerShell yükleyicisini kullanırsınız ve eğer bir geliştirme bağımlılığı olarak sabitlemeyi tercih ederseniz bir npm paketi de mevcuttur:

npm install -g postman-cli

İkili dosya postman'dır. CI'da Postman API anahtarıyla kimlik doğrulaması yaparsınız; bu, Postman'ın işlem hatları için önerdiği yöntemdir:

postman login --with-api-key $POSTMAN_API_KEY

Ardından bir koleksiyonu kimliğine göre veya dışa aktardıysanız yerel bir dosya yoluyla çalıştırırsınız:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Postman CLI'a çok sadakat kazandıran kısım, çalıştırma sonrası olanlardır. Oturum açtığınızda, çalıştırma sonuçlarını doğrudan Postman bulutuna gönderir ve bunlar çalışma alanınızda koleksiyonla birlikte görünür. Test geçmişi, çalıştırma karşılaştırmaları ve ekibin görebileceği pano, herhangi bir ek altyapıya gerek kalmadan orada mevcuttur. Zaten Postman'da yaşayan bir ekip için bu gidiş-dönüş gerçekten kullanışlıdır ve kalmak için geçerli bir nedendir.

Apidog CLI neyi iyi yapar

Apidog, aynı işlem hattına farklı bir yoldan gider. Testleri Apidog uygulaması içinde görsel olarak oluşturursunuz: birden çok isteği tek bir test senaryosunda zincirlersiniz, her yanıta onaylar eklersiniz, bir yanıttan bir değer alır ve sonraki isteğe beslersiniz ve tüm senaryoyu 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. Kendi test formatı yoktur. Apidog projenize ulaşır, kimliğine göre adlandırdığınız senaryoyu bulur ve uygulamadaki gibi çalıştırır, ardından rapor verir.

Bunun getirisi, kimsenin aynı testin iki kopyasını sürdürmemesidir. Görsel düzenleyicide oluşturduğunuz senaryo, CI'da çalışan testtir. Çalışan bir testi bir betik olarak yeniden ifade etme ve ardından betiği hata ayıklama adımı yoktur. Hızlı yazım döngüsü ve otomasyon döngüsü tek bir doğruluk kaynağını paylaşır. Çok adımlı akışlar için, önce giriş yapma, sonra oluşturma, sonra okuma, sonra silme gibi işlemlerde, bu görsel zincirleme aksi takdirde elle yazacağınız birçok bağlayıcı kodu kurtarır. Bu akışları oluşturma mekanizmaları API test otomasyonu için test senaryoları rehberinde ele alınmıştır.

Kurulum tek bir npm komutudur:

npm install -g apidog-cli

İkili dosya apidog'dur. Tipik bir çalıştırma, bir senaryoyu kimliğine göre adlandırır, bir ortam seçer, bir yineleme sayısı belirler ve bir erişim belirteciyle kimlik doğrulaması yapar:

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

Bu kimlikleri elle yazmazsınız. Apidog'da test senaryosunu açın, CI/CD sekmesine geçin, bir erişim belirteci oluşturmak için tıklayın ve Apidog, senaryo kimliği ve ortam kimliği zaten doldurulmuş olarak tam komutu sizin için oluşturur. Bir kez kopyalayın, belirteci bir CI sırrına taşıyın ve iş akışınızda $APIDOG_ACCESS_TOKEN olarak referans gösterin.

Belirteç ve kimlik modeli, Postman CLI'dan en net ayrışmadır. Apidog, CLI'ın ağ üzerinden getirdiği ve belirteçle kimliği doğrulanmış bir projede depolanan testleri çalıştırır. Raporlama için ayrı bir bulut seçeneği de yoktur: yerel yapıtlar için --out-dir seçeneğini belirlersiniz ve bir genel bakışın Apidog bulutuna gönderilmesini istediğinizde yalnızca --upload-report eklersiniz. Raporlar, onları koyduğunuz yerde kalır.

Karşılaştırma

Bu tablodan iki şey göze çarpıyor. Birincisi, her iki çalıştırıcı da CI'ın temel gereksinimlerini neredeyse aynı şekilde kapsar: ortam seçimi, veri odaklı yineleme, önemli dört rapor formatı ve başarısızlık durumunda sıfır olmayan bir çıkış. Tek ihtiyacınız olan kötü bir birleştirmede kırmızı yanan bir çalıştırıcı ise, ikisinden biri işinizi görecektir. İkincisi, gerçek ayrım testin nerede yaşadığı ve onu nasıl yazdığınızla ilgilidir. Postman CLI, Postman çalışma alanınızda yaşayan bir koleksiyonu çalıştırır. Apidog CLI, Apidog projenizde yaşayan görsel bir senaryoyu çalıştırır.

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

Bir çalıştırıcı, işlem hattında değerini iki davranışla kanıtlar: yazdığı rapor ve döndürdüğü çıkış kodu. Bu ikisini doğru yapın, gerisi bağlantıdır.

Postman CLI, virgülle ayrılmış bir raporlayıcı listesi alır ve oturum açtığınızda sonuçları Postman bulutuna da gönderir:

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

junit raporlayıcısı, CI panonuzun bir geçiş veya başarısızlık ağacına ayrıştırdığı rapordur. --bail bayrağı, ilk başarısız istek, test veya onayda çalıştırmayı durdurur, bu da bir duman testinde geri bildirimi hızlı tutar. --bail'i kaldırırsanız her şeyi çalıştırır, ardından tüm hataları birlikte raporlar. CLI, herhangi bir hatada sıfır olmayan bir değerle çıkar, böylece derleme kendi kendine kırmızıya döner.

Apidog CLI, aynı -r raporlayıcı fikrini kullanır ve her şeyi tek bir çıktı dizini altına yazar:

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

--on-error bayrağı, senaryo içi davranışı şekillendirir: end ilk hatada durur ve varsayılandır, continue her adımı çalıştırır, böylece tüm hataları tek bir raporda toplarsınız ve ignore, çalıştırmayı aksatmadan bilinen hatalı bir adımı atlar. Her iki durumda da, bir şey başarısız olursa süreç sıfır olmayan bir değerle sona erer ve JUnit XML, panonuzun alması için ./apidog-reports konumuna yerleşir.

Pratik sonuç: her ikisi de JUnit XML yazar, her ikisi de derlemeyi doğru bir şekilde başarısız kılar ve her ikisi de daha sonra açabileceğiniz bir HTML raporu arşivler. Raporlamadaki fark, bulut gidiş-dönüşüdür. Postman, kimlik doğrulaması yapıldığında sonuçları varsayılan olarak bulutuna gönderir. Apidog, yüklemesini istemediğiniz sürece raporları yerel tutar. Soyut olarak ikisinden biri daha iyi değildir; biri barındırılan bir geçmişi düşünmeden isteyen ekiplere uyar, diğeri ise çalıştırıcıdan neyin ayrılacağına tam olarak karar vermek isteyen ekiplere uyar.

Her birini GitHub Actions'a bağlama

Bir GitHub Actions görevinin şekli her ikisi için de aynıdır: depoyu kontrol et, Node'u kur, CLI'ı yükle, testleri çalıştır ve başarısız çıkış kodu birleştirmeyi engeller. Sırrı depo ayarlarınızda saklayın, asla iş akışı dosyasında değil.

İşte Postman CLI versiyonu:

- 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

Ve Apidog CLI versiyonu:

- 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

Her ikisi de kısa, her ikisi de okunabilir ve her ikisi de işlem hattınızın önemsediği düzeyde aynı şekilde davranır: geçen bir çalıştırma sıfırla çıkar ve birleştirme devam eder, başarısız bir çalıştırma sıfır olmayan bir değerle çıkar ve birleştirme engellenir. Bir GitHub iş akışında API testlerini çalıştırmanın daha derinlemesine bir anlatımını istiyorsanız, GitHub Actions ile API test otomasyonu adım adım ilerler. Jenkins kullanıcıları için, aynı fikir Apidog otomatik testlerini Jenkins ile entegre etme makalesinde açıklanmıştır.

Peki CI'da hangisi kazanır?

Tek bir kazanan yok, çünkü doğru cevap testlerinizin nerede yaşadığına ve ekibinizin bunları nasıl yazıp saklamak istediğine bağlıdır.

Apidog CLI, görsel yazımı ve tek bir doğruluk kaynağını barındırılan bir bulut geçmişinden daha çok önemsediğinizde kazanır. Senaryoyu görsel düzenleyicide bir kez oluşturursunuz, istek zincirleme ve onaylar sizin için halledilir ve aynı senaryo CI'da referansla çalışır. Raporların yerel mi kalacağına yoksa yüklenip yüklenmeyeceğine siz karar verirsiniz. Ve Apidog aynı çalışma alanında tasarım, sahteleştirme ve dokümantasyonu kapsadığı için, test senaryosu kontrol ettiği API sözleşmesinin yanında durur, bu da testlerin ve belirtimlerin birbirinden uzaklaşmasını engeller. Platformları daha geniş bir şekilde değerlendiren ekipler, Apidog vs Postman karşılaştırmasını okuyabilir.

Postman CLI, ekibiniz zaten Postman'ı kullanıyorsa kazanır. Koleksiyonlarınız orada, ortamlarınız orada ve herhangi bir kurulum yapmadan Postman bulutunda çalıştırma geçmişi istiyorsunuz. Her çalıştırmadaki bulut gidiş-dönüşü bu kurulum için gerçek bir kolaylıktır ve araç resmi olarak imzalanmış ve desteklenmektedir. Ekibinizi bu açıklama tanımlıyorsa, çalıştırıcı değiştirmek size pek bir şey kazandırmaz.

Postman bulut modeli tarafından kısıtlandığınızı hissediyorsanız veya sadece testleri bir kez yazıp her yerde çalıştırmak istiyorsanız, yapmanız gereken açık. Apidog'u indirin, bir senaryo oluşturun, CI/CD sekmesini açın ve oluşturulan apidog run komutunu işlem hattınıza kopyalayın. Kurulumun tamamı bu kadar.

Sıkça Sorulan Sorular

Postman CLI, Newman ile aynı mıdır? Hayır. Newman, daha eski açık kaynaklı npm çalıştırıcısıdır. Postman CLI, Newman'ın temeli üzerine inşa edilmiş, Postman tarafından imzalanmış ve desteklenen, Postman bulutuna yerleşik raporlama özelliğine sahip daha yeni bir araçtır. Postman tarafındaki iki seçenek arasında seçim yapıyorsanız, Postman CLI vs Newman farklılıkları detaylandırır.

CI'da herhangi bir CLI için hesap veya belirteç gerekiyor mu? Her ikisi için de evet, ancak şekli farklıdır. Postman CLI, postman login --with-api-key aracılığıyla bir Postman API anahtarıyla kimlik doğrulaması yapar. Apidog CLI, --access-token olarak geçirilen bir erişim belirteciyle kimlik doğrulaması yapar. Her ikisini de bir CI sırrı olarak saklayın, asla iş akışı dosyasında değil.

Her iki çalıştırıcı da bir test başarısız olduğunda derlemeyi başarısız kılar mı? Evet. Her ikisi de başarısız olan herhangi bir test veya onayda sıfır olmayan bir durum koduyla çıkar, bu da CI sisteminize derlemeyi kırmızı olarak işaretlemesini ve birleştirmeyi engellemesini söyler. Postman CLI, ilk başarısızlıkta durmak için --bail kullanır; Apidog CLI ise varsayılanı olan --on-error end'i kullanır.

Raporlarımı bir buluta göndermek yerine yerel tutabilir miyim? Apidog CLI, raporları varsayılan olarak yerel tutar ve --out-dir dizinine yazar; yalnızca --upload-report ile yüklersiniz. Postman CLI da yerel raporlar yazar, ancak oturum açtığınızda çalıştırma sonuçlarını otomatik olarak Postman bulutuna da gönderir.

Senaryom için tam Apidog çalıştırma komutunu nasıl alırım? Apidog'da test senaryosunu açın, CI/CD sekmesine geçin, bir erişim belirteci oluşturun ve Apidog, senaryo kimliği ve ortam kimliği zaten doldurulmuş olarak tam apidog run komutunu sizin için oluşturur. Kopyalayın, belirteci bir CI sırrına taşıyın ve işiniz bitti. Mevcut her bayrak için apidog run --help komutunu çalıştırın.

Postman bulutundan göç eden bir ekip hangisini seçmeli? Ayrılma nedeniniz bulut merkezli model veya fiyatlandırma ise, Apidog CLI uygundur, çünkü projenizden tek bir görsel senaryo çalıştırır ve çalıştırıcıdan neyin ayrılacağına sizin karar vermenizi sağlar. Platformların çalıştırıcının ötesinde nasıl hizalandığını görmek için Apidog vs Postman karşılaştırması ile başlayın.