API testleri artık GUI'ye bağlı değil. Testleri ekranı olmayan CI kapsayıcılarında, yalnızca SSH ile erişilebilen staging sunucularında veya sadece kabuk komutlarıyla çalışan yapay zeka ajanlarında çalıştırabilirsiniz. Bu ortamlarda kritik çıktı şudur: komut geçti mi, başarısız mı oldu ve işlem hangi çıkış koduyla tamamlandı?
Bu rehber, gerçek API test işlerini doğrudan terminalden çalıştırabileceğiniz araçlara odaklanır. Burada “terminal tabanlı” demek; aracı paket yöneticisiyle kurabilmeniz, tek bir kabuk komutuyla testleri başlatabilmeniz ve CI'ın kullanacağı çıkış kodunu alabilmeniz demektir.
Değerlendirme ölçütleri:
- Yerleşik assertion/onaylama desteği
- Çok adımlı akışları çalıştırabilme
- CI için JSON, JUnit veya HTML raporları
- Sürümleme ve tekrar çalıştırma kolaylığı
- Bakım ve ekosistem durumu
curl gibi manuel istemciler de listede yer alıyor. Ancak bunlar çoğunlukla test çalıştırıcılarından ziyade keşif, hata ayıklama ve kabuk betikleri için uygundur. GUI ve barındırılan araçları da kapsayan daha geniş bir karşılaştırma için en iyi ücretsiz API test araçları derlemesine bakabilirsiniz.
Bir test aracını istemciden ayıran nedir?
Terminal istemcisi istek gönderir ve yanıtı gösterir. Terminal test aracı ise yanıtı değerlendirir, assertion sonuçlarını raporlar ve başarısızlıkta CI'ı durdurabilecek sıfır olmayan bir çıkış kodu döndürür.
Bir aracı test çalıştırıcısı olarak değerlendirmek için şu dört özelliği arayın:
-
Yerleşik onaylamalar: Durum kodu, başlık ve gövde kontrolleri araç içinde tanımlanabilmelidir. Her kontrol için
jqve özel kabuk kodu yazmak zorunda kalmamalısınız. -
Anlamlı çıkış kodları: Başarıda
0, başarısızlıkta sıfır olmayan bir kod dönmelidir. - Tekrarlanabilir test tanımları: Testler kabuk geçmişinde değil; Git ile sürümleyebileceğiniz dosyalarda, koleksiyonlarda veya projelerde yaşamalıdır.
- Makine tarafından okunabilir raporlar: Terminal çıktısına ek olarak JSON, JUnit veya HTML çıktısı CI ve kontrol panelleri için önemlidir.
1. Apidog CLI: Senaryoyu görsel olarak tasarlayın, her yerde başsız çalıştırın
Apidog, API tasarımı, test, modelleme ve dokümantasyonu bir araya getiren bir API platformudur. apidog-cli, bu platformdaki test senaryolarını terminalden çalıştırmanızı sağlar.
Önce görsel editörde zincirlenmiş istekleri, değişken çıkarımlarını ve assertion'ları tanımlayın. Ardından aynı senaryoyu dizüstü bilgisayarınızda, CI ortamında veya bir ajan içinde apidog run ile çalıştırın.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
# Senaryonun CI/CD sekmesinden üretilen komutu kopyalayın
apidog run -t <scenario_id> -e <env_id> -r cli
Uygulama adımları:
- Apidog projenizde test senaryosunu açın.
- İstek adımlarını, değişkenleri ve assertion'ları tanımlayın.
- CI/CD sekmesine gidin.
- Ortam ve senaryo kimliklerini içeren oluşturulmuş komutu kopyalayın.
- Bu komutu GitHub Actions, GitLab CI veya başka bir pipeline adımına ekleyin.
Raporlayıcılar cli, html, json ve junit formatlarını destekler. Raporlar apidog-reports/ dizinine yazılır; böylece aynı test çalıştırmasından terminal çıktısı, CI özeti ve saklanabilir artefakt üretebilirsiniz.
CSV veya JSON dosyalarından veri odaklı iterasyonlar çalıştırabilirsiniz. Çıktı ayrıca agentHints.nextSteps içeren yapılandırılmış JSON sağlayabilir; bu, yapay zeka kodlama ajanlarının ekran kazıma yapmadan sonraki adımı belirlemesine yardımcı olur.
Node.js 16 veya üzeri gerekir.
En iyi kullanım alanı: Karmaşık ve çok adımlı senaryoları görsel olarak hazırlayıp aynı tanımı yerelde, CI'da ve ajanlarda çalıştırmak isteyen ekipler.
Sınırlama: Açık kaynak değildir ve ad-hoc HTTP isteği göndermek için tasarlanmamıştır. Senaryolar bir Apidog projesinde yaşar. Tüm komutlar için Apidog CLI kapsamlı rehberi inceleyebilirsiniz.
2. Hurl: Tek Rust ikili dosyasında düz metin HTTP testleri
Hurl, düz metin dosyalarındaki HTTP isteklerini çalıştırır ve yanıtlar üzerinde assertion uygular. Rust ve libcurl ile oluşturulmuştur; tek bir ikili dosya olarak dağıtıldığı için ek çalışma zamanı gerektirmez.
Test dosyaları ham HTTP'ye yakın okunur. Bu nedenle pull request incelemelerinde anlaşılması kolaydır.
brew install hurl
# veya:
cargo install --locked hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }
HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF
hurl --test login.hurl
--test kullanıldığında assertion başarısız olursa Hurl sıfır olmayan çıkış kodu döndürür. CI için temel kullanım örneği:
- name: API sözleşme testlerini çalıştır
run: hurl --test tests/*.hurl
En iyi kullanım alanı: Git'te düz metin olarak saklanan sözleşme testleri ve smoke testler.
Sınırlama: HTTP odaklıdır. gRPC sürmez veya yük testi üretmez. Karmaşık iş mantığı genellikle daha fazla .hurl dosyası anlamına gelir.
3. Newman: Postman koleksiyonlarını başsız çalıştırın
Newman, Postman koleksiyonlarının açık kaynaklı komut satırı çalıştırıcısıdır ve Apache-2.0 lisanslıdır. Ekibiniz istekleri ve testleri zaten Postman'da tanımlıyorsa koleksiyonu JSON olarak dışa aktararak GUI olmadan çalıştırabilirsiniz.
npm install -g newman
newman run collection.json -e staging.json
CI'da koleksiyon ve ortam dosyalarını depoya ekleyin:
- name: Postman koleksiyonunu çalıştır
run: newman run collection.json -e environments/staging.json
Newman bir test başarısız olduğunda sıfır olmayan kodla çıkar. Bu nedenle ek kabuk kontrolü yazmadan pipeline kapısı olarak kullanılabilir.
En iyi kullanım alanı: Postman'a yatırım yapmış ve mevcut koleksiyonlarını ek lisans olmadan CI'da çalıştırmak isteyen ekipler.
Sınırlama: Yalnızca Postman koleksiyonu formatını çalıştırır. Test yazımı hâlâ çoğunlukla Postman GUI'sinde yapılır.
4. Postman CLI: Buluta bağlı birinci taraf çalıştırıcı
Postman CLI, Postman'ın kapalı kaynaklı resmi CLI çalıştırıcısıdır. Newman'dan farklı olarak Postman hesabınızla oturum açar ve koleksiyonları kimlikleri üzerinden doğrudan çalışma alanından çalıştırabilir.
postman login --with-api-key <YOUR_API_KEY>
postman collection run <collection_id> -e <environment_id>
Bu yaklaşımda koleksiyon ve ortam JSON dosyalarını CI deposuna dışa aktarmak zorunda kalmazsınız.
En iyi kullanım alanı: Koleksiyonlarını Postman bulutunda yönetmek ve sonuçları Postman ekosistemine raporlamak isteyen ekipler.
Sınırlama: Kapalı kaynaklıdır ve Postman hesabına bağlıdır. Newman ve Postman CLI arasında seçim yaparken çalışma modelinizi netleştirin. Ayrıntılı değerlendirme için Postman CLI vs Newman karşılaştırmasına bakın.
5. Bruno CLI: Git-yerel .bru koleksiyonları
Bruno, koleksiyonları normal klasörlerde düz metin .bru dosyaları olarak saklar. Böylece API istekleri, assertion'lar ve betikler uygulama kodunuz gibi depoda yaşar.
CLI paketi @usebruno/cli ile gelir ve koleksiyonları bru run üzerinden çalıştırır.
npm install -g @usebruno/cli
# Mevcut koleksiyon klasöründeki istekleri staging ortamında çalıştırın
bru run --env staging
CI'a eklemek için:
- name: Bruno API testlerini çalıştır
run: bru run --env staging
Bruno JSON, JUnit ve HTML raporları üretebilir. Bu sayede test sonuçlarını CI arayüzünde gösterebilir veya artefakt olarak saklayabilirsiniz.
En iyi kullanım alanı: Koleksiyonları Git ile incelemek, çevrimdışı çalışmak ve test tanımlarını kodla birlikte saklamak isteyen ekipler.
Sınırlama: Düz metin tabanlı yazım, geliştirici ağırlıklı ekipler için daha doğal olabilir. Ekosistemi Postman'a göre daha ახალგაზრდadır. Karşılaştırma için Bruno CLI vs Apidog CLI yazısını inceleyin.
6. Schemathesis: Şemadan test üretin
Schemathesis, OpenAPI veya GraphQL şemanızı okur ve Hypothesis tabanlı özellik testleriyle çok sayıda test girdisi üretir. Tek tek her edge case'i yazmak yerine, aracı 500 hataları, şema ihlalleri ve sözleşmeyle çelişen yanıtları aramak için kullanabilirsiniz.
pip install schemathesis
schemathesis run https://api.example.com/openapi.json
Sürüm öncesi doğrulamada örnek bir kullanım:
schemathesis run \
--base-url https://staging.example.com \
openapi.yaml
En iyi kullanım alanı: Manuel testlerin çoğunlukla atladığı uç durumları yakalamak ve OpenAPI sözleşmesini doğrulamak.
Sınırlama: Çalışmak için gerçek ve güncel bir şema gerekir. Büyük API'lerde çok sayıda çıktı oluşabilir; kancalar ve seçeneklerle kapsamı filtrelemeniz gerekebilir.
7. Step CI: Çok adımlı akışlar için YAML
Step CI, bir API iş akışını tek bir YAML dosyasında tanımlar. Adımları, yakalanan değerleri ve assertion'ları deklaratif biçimde yazabilirsiniz.
REST, GraphQL, gRPC, tRPC ve SOAP akışlarını destekler; ayrıca yanıtları OpenAPI şemasına göre doğrulayabilir.
npm install -g stepci
stepci run workflow.yml
Örnek kullanım modeli:
- Giriş isteği gönderin.
- Yanıttan erişim jetonunu yakalayın.
- Jetonu sonraki isteğin
Authorizationbaşlığına ekleyin. - Yanıt durumunu ve gövdesini doğrulayın.
- name: Giriş yap
http:
url: https://api.example.com/login
method: POST
- name: Korumalı kaynağı çağır
http:
url: https://api.example.com/profile
method: GET
En iyi kullanım alanı: “Giriş yap, token al, token ile isteği gönder” gibi çok adımlı akışları ek betik dili kullanmadan YAML ile tanımlamak.
Sınırlama: Node.js çalışma zamanı gerektirir. Sürüm sıklığı yavaşladığı için pipeline standardı hâline getirmeden önce depo etkinliğini kontrol edin.
8. curl: Her yerde bulunan temel araç
curl, macOS, çoğu Linux dağıtımı ve güncel Windows sürümlerinde hazır bulunur. Bu nedenle kilitli veya minimal ortamlarda en düşük maliyetli seçenektir.
Tek başına test çerçevesi değildir; ancak durum kodunu okuyup kabukla karar vermek için kullanılabilir.
# JSON POST isteği gönderin ve sadece HTTP durum kodunu yazdırın
curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://api.example.com/orders \
-H "Content-Type: application/json" \
-d '{"sku":"A-102","qty":2}'
Basit bir CI kapısı için durum kodunu kontrol edebilirsiniz:
status=$(
curl -s -o /dev/null -w "%{http_code}" \
https://api.example.com/health
)
test "$status" = "200"
Bu komutta test başarısız olursa kabuk sıfır olmayan çıkış kodu döndürür.
En iyi kullanım alanı: Tek seferlik istekler, hata ayıklama, kısa betikler ve ek araç kurulumunun mümkün olmadığı ortamlar.
Sınırlama: Assertion'lar tamamen kendin yap modelindedir. JSON gövdesini doğrulamak için genellikle jq, değer karşılaştırmaları ve manuel hata yönetimi gerekir. curl istek gönderir ve yanıtı gösterir; doğrudan test çalıştırıcısı değildir. Daha güçlü seçenekler için REST API testi için curl alternatifleri rehberine bakın.
9. HTTPie ve xh: Okunabilir manuel istekler
HTTPie, terminalden HTTP isteği göndermeyi daha okunabilir hâle getirir. JSON alanlarını anahtar=değer biçiminde yazabilir, biçimlendirilmiş ve renklendirilmiş yanıt alabilirsiniz.
xh, benzer sözdizimini Rust ile tek bir statik ikili olarak uygular. Daha hızlı başlatma sunar ve --curl ile eşdeğer curl komutunu yazdırabilir.
http POST api.example.com/users name=acme plan=pro
# Aynı sözdizimi, tek ikili yaklaşımı
xh POST api.example.com/users name=acme plan=pro
Bir isteği curl komutuna dönüştürmek için:
xh --curl POST api.example.com/users name=acme plan=pro
En iyi kullanım alanı: API'yi manuel keşfetmek, endpoint davranışını incelemek ve gerçek test senaryosunu yazmadan önce hızlı denemeler yapmak.
Sınırlama: İkisi de istemcidir, test çalıştırıcısı değildir. Yanıt üzerinde yerleşik assertion çalıştırmazlar. HTTPie Python çalışma zamanı taşırken xh daha küçük özellik kümesini daha hızlı başlangıç için tercih eder.
10. k6: Soru kapasite olduğunda
k6, “yanıt doğru mu?” sorusundan çok “servis trafik altında dayanıyor mu?” sorusuna yanıt verir. Grafana tarafından geliştirilen, Go tabanlı tek ikili bir yük test aracıdır ve test senaryoları JavaScript ile yazılır.
Eşik tanımlarıyla yük testini CI kapısına dönüştürebilirsiniz. Bir eşik aşılırsa k6 sıfır olmayan çıkış koduyla tamamlanır.
brew install k6
k6 run load.js
Örneğin load.js içinde sanal kullanıcıları, süreyi ve eşikleri tanımlarsınız:
import http from "k6/http";
import { check } from "k6";
export const options = {
vus: 10,
duration: "30s",
thresholds: {
http_req_failed: ["rate<0.01"],
http_req_duration: ["p(95)<500"],
},
};
export default function () {
const response = http.get("https://api.example.com/health");
check(response, {
"durum 200": (res) => res.status === 200,
});
}
En iyi kullanım alanı: Fonksiyonel testlerle aynı depoda tutulan, yerelde veya CI'da çalıştırılan performans ve yük kontrolleri.
Sınırlama: AGPL-3.0 lisanslı bir yük aracıdır; fonksiyonel API test istemcisi değildir. Anlamlı senaryolar oluşturmak için JavaScript API'sini öğrenmeniz gerekir.
Etkileşimli bir terminal arayüzü mü istiyorsunuz?
Kabuktan çıkmadan Postman benzeri bir deneyim istiyorsanız atac ve posting gibi TUI istemcileri ayrı bir kategoridir. Terminal içinde istek düzenleyicileri sunarlar ve API keşfi için faydalıdırlar; ancak tipik olarak CI pipeline'ını durduracak test çalıştırıcıları değildirler.
Bu kategori için en iyi terminal ve TUI REST API istemcileri derlemesini inceleyin.
Karşılaştırma tablosu
| Araç | Görev | Yerleşik onaylamalar | Kurulum | Açık kaynak |
|---|---|---|---|---|
| Apidog CLI | Görsel olarak tasarlanmış senaryoları CI'da çalıştırma | Evet | npm i -g apidog-cli |
Hayır, ücretsiz katman var |
| Hurl | Düz metin HTTP testleri | Evet | brew install hurl |
Apache-2.0 |
| Newman | Postman koleksiyonlarını başsız çalıştırma | Evet | npm i -g newman |
Apache-2.0 |
| Postman CLI | Bulut bağlantılı Postman çalıştırmaları | Evet | Postman yükleyici | Hayır |
| Bruno CLI | Git-yerel .bru koleksiyonları |
Evet | npm i -g @usebruno/cli |
MIT |
| Schemathesis | Şemadan bulanıklaştırma testi üretme | Oluşturulmuş | pip install schemathesis |
MIT |
| Step CI | Çok adımlı YAML akışları | Evet | npm i -g stepci |
MPL-2.0 |
| curl | Ham istekler ve betikleme | Kendin yap | Önceden kurulu | Evet |
| HTTPie / xh | Okunabilir manuel istekler | Hayır |
brew install httpie / xh
|
Evet |
| k6 | Geç/kal eşikleriyle yük testi | Eşikler | brew install k6 |
AGPL-3.0 |
Nasıl seçim yapılır?
Araçtan önce iş yükünüzü seçin:
- Mevcut Postman koleksiyonlarını yarın CI'a almak istiyorsanız: Newman veya Postman CLI kullanın.
- Testleri Git'te incelenebilir metin dosyaları olarak tutmak istiyorsanız: Hurl veya Bruno CLI seçin.
- Güvenilir bir OpenAPI şemanız varsa: Schemathesis ekleyin ve otomatik üretilen edge case testleri çalıştırın.
- Giriş, token alma ve sonraki istekte token kullanma gibi akışlarınız varsa: Step CI veya Apidog CLI değerlendirin.
- Sadece hızlı manuel deneme yapacaksanız: curl, HTTPie veya xh kullanın.
- Kapasite ve gecikme ölçmeniz gerekiyorsa: k6 kullanın.
- Senaryoları görsel editörde yazıp her ortamda aynı komutla çalıştırmak istiyorsanız: Apidog CLI kullanın.
Apidog CLI, aynı projede API tasarımı, sahte veri ve dokümantasyon da tutmak isteyen ekipler için entegre platform seçeneğidir. Daha fazla ayrıntı için Apidog CLI: Terminalinizde yaşayan API istemcisi makalesine bakın. Test katmanlarını birlikte planlamak için API test stratejileri rehberi de yararlıdır.
Sıkça sorulan sorular
API'leri tamamen terminalden test edebilir miyim?
Evet. Testleri dosya tabanlı olarak Hurl, Bruno veya Step CI ile yazabilir; ya da görsel editörde Apidog ve Postman ile oluşturabilirsiniz. Ardından ilgili CLI ile başsız çalıştırırsınız. Test çalıştırıcısı başarısızlıkta sıfır olmayan bir çıkış kodu döndürdüğü sürece CI bu sonucu kapı olarak kullanabilir.
Terminal API istemcisi ile test aracı arasındaki fark nedir?
İstemci (curl, HTTPie, xh) istek gönderir ve yanıtı gösterir. Test aracı (apidog-cli, Hurl, Newman) yanıta assertion uygular ve kontrol başarısız olduğunda sıfır olmayan çıkış koduyla tamamlanır.
Kısaca:
- İstemciler API'yi keşfetmenize yardımcı olur.
- Test araçları pipeline için kalite kapısı görevi görür.
Hangileri CI pipeline'larında çalışır?
Bu listedeki tüm test çalıştırıcıları CI'da kullanılabilir:
apidog run
hurl --test
newman run
postman collection run
bru run
schemathesis run
stepci run
k6 run
Başarısızlık durumunda sıfır olmayan kod döndürürler. Uygulamalı bir pipeline örneği için GitHub Actions'ta Apidog CLI testlerini çalıştırma rehberine bakın.
Bu araçlardan hangisi yük testi yapar?
Bu listedeki yük testi uzmanı k6'dır. Fonksiyonel test araçları doğruluğu kontrol eder; k6 ise kapasite, hata oranı ve gecikme eşiklerini değerlendirir. Birçok ekip fonksiyonel test çalıştırıcısını k6 ile birlikte kullanır.
OpenAPI belirtimine ihtiyacım var mı?
Yalnızca Schemathesis, şemadan test ürettiği için OpenAPI veya GraphQL şemasına ihtiyaç duyar. Diğer araçlarda şema zorunlu değildir ancak faydalı olabilir:
- Apidog, OpenAPI 3.x, Swagger 2.0 ve Postman koleksiyonlarını içe aktarabilir.
- Step CI, yanıtları şemaya göre doğrulayabilir.
- Hurl, Bruno ve Newman ise doğrudan tanımladığınız istek ve assertion'larla çalışabilir.
Temel desen değişmez: testleri rahat yazabileceğiniz yerde oluşturun, ardından terminal çalıştırıcısının CI'a güvenilir bir çıkış kodu verdiğinden emin olun. Tek platformda hem yazım hem çalıştırma istiyorsanız Apidog'u indirin, editörde bir senaryo oluşturun ve apidog run komutunu CI adımınıza ekleyin.
Top comments (0)