Başsız (Headless) API testi, döngüde herhangi bir grafik arayüz (GUI) olmadan bir API'yi doğrulamak anlamına gelir. Testleri sözleşmeden yönlendirir, bir terminalde veya bir CI (Sürekli Entegrasyon) hattında çalıştırır ve sonuçları metin veya yapılandırılmış raporlar olarak okursunuz. Eğer bir derlemede Apidog CLI testleri çalıştırdıysanız veya komut satırından bir koleksiyonu yürütmek için Newman gibi bir çalıştırıcı kullandıysanız, zaten başsız test yapmışsınız demektir. Bu kılavuz, terimin ne anlama geldiğini, API ürün olduğunda neden önemli olduğunu ve CLI'nin nerede devreye girdiğini açıklar.
Başsız API testi, tanımlanmıştır
"Başsız" terimi, görünür bir pencere olmadan çalışan başsız tarayıcının kullanıldığı tarayıcı testlerinden ödünç alınmıştır. Bu fikri API'lere uyguladığınızda aynı şekli elde edersiniz: testler bir GUI olmadan, bir insanın düğmelere tıklaması veya bir ekranı izlemesi olmadan çalışır.
Başsız bir API testinin üç özelliği vardır:
- Yürütme yolunda GUI yok. Test bir kabukta, bir kapsayıcıda veya bir CI işinde çalışır. Kimse onu başlatmak için bir uygulama açmaz.
- Sözleşmeyle yönlendirilir. Test, API'nin istek ve yanıt şekline göre tanımlanır; genellikle bir OpenAPI belirtimi veya dışa aktarılmış bir koleksiyon olarak. Sözleşme, doğruluk kaynağıdır.
- Makine tarafından okunabilir çıktı. Sonuçlar çıkış kodları, konsol metni, JUnit XML veya JSON olarak döner. Bir hat, bir kişinin bir gösterge panosu okumasına gerek kalmadan onlar üzerinde hareket edebilir.
Bütün fikir bu. Bir API'nin kendi ekranı yoktur, bu yüzden onu bir ekran aracılığıyla test etmek her zaman ihtiyacınız olmayan bir katmandı. Başsız test, bu katmanı kaldırır.
API ürün olduğunda neden önemli?
Giderek artan sayıda ekip için API, destekleyici bir aktör değildir. Müşterilerin para ödediği şeydir. API'niz ürün olduğunda, her uç nokta bir sözdür ve bozuk bir uç nokta bozuk bir üründür.
Bu, test etme şeklinizi değiştirir. Her sürümden önce birinin manuel olarak bir UI'ye tıklamasını bekleyemezsiniz. Her commit'te, her birleştirmede ve her dağıtımda, insan müdahalesi olmadan çalışan testlere ihtiyacınız var. Başsız test, bunu mümkün kılan şeydir.
Ayrıca günümüzde API'leri tüketenlerle de eşleşiyor. Diğer hizmetler API'nizi çağırır. Mobil istemciler çağırır. Yapay zeka ajanları çağırır. Hiçbiri bir GUI kullanmaz, bu yüzden bir GUI aracılığıyla test etmek, gerçek tüketicilerin nasıl davrandığı hakkında size çok az şey söyler. Başsız bir test, çağıranla aynı dili konuşur: bir istek gönderilir, bir yanıt döner ve bir onay sözleşmeyi kontrol eder.
Pratik bir faydası da var. Başsız testler tekrarlanabilir. Aynı komut, dizüstü bilgisayarınızda veya sabah 2'de bir Jenkins işinde çalışsa da aynı çıktıyı üretir. Bu tekrarlanabilirlik, API testi için sağlam CI/CD'nin temelidir.
GUI ve manuel testlerden farkı nedir?
Manuel test ve GUI odaklı test yanlış değildir. Keşif, tek seferlik hata ayıklama ve otomatikleştirmeden önce bir isteği tasarlama için iyidirler. Fark, her yaklaşımın nerede olması gerektiğidir.
| Yön | Manuel / GUI testi | Başsız API testi |
|---|---|---|
| Tetikleyici | Bir kişi tıklar veya gönderir | Bir komut, kanca veya boru hattı aşaması |
| Nerede çalışır | Bir masaüstü veya web uygulaması | Terminal, kapsayıcı, CI çalıştırıcısı |
| Tekrarlanabilirlik | Kişiye bağlıdır | Her çalıştırmada aynıdır |
| Çıktı | Ekranda, görsel | Çıkış kodları, günlükler, JUnit/JSON raporları |
| CI/CD'ye uyar | Bağlaması zor | Bunun için yapıldı |
| En iyisi | Keşif, ilk hata ayıklama | Regresyon, kapılar, zamanlanmış çalıştırmalar |
Dürüst olmak gerekirse: ikisini de kullanacaksınız. Bir GUI'de keşfeder ve tasarlarsınız, ardından oluşturduğunuz testi her sürümü koruyan başsız bir çalıştırmaya dönüştürürsünüz. GUI, bir testin doğduğu yerdir. CLI, yaşadığı yerdir.
CLI'nin rolü
Komut satırı, bir testi başsız yapan şeydir. Bir CLI çalıştırıcısı, test tanımınızı alır, hedef bir ortama karşı yürütür ve bir makinenin okuyabileceği bir sonuç döndürür. Pencere yok, tıklama yok.
Yetenekli bir başsız çalıştırıcı genellikle birkaç şeyi halleder:
- Bir ortamı işaret etme. Aynı testlerin hazırlık ortamına, ardından üretime karşı çalışması için bir temel URL, değişkenler veya bir ortam kimliği geçersiniz.
- Veri odaklı çalıştırmalar. Bir CSV veya JSON dosyası besleyerek, tek bir testin birçok giriş satırı üzerinde döngü yapmasını sağlarsınız. Bu, test senaryolarını kopyala yapıştır yapmadan uç durumları nasıl kapsadığınızdır. Bu desen için parametreli test bölümüne bakın.
- Raporlar. Çalıştırıcı, boru hattınızın saklayabileceği veya başarısız olabileceği çıktıyı, konsol metni, HTML veya JSON gibi biçimlerde yayar.
- Bir çıkış kodu. Sıfır olmayan bir çıkış kodu derlemeyi başarısız kılar. Bu tek davranış, bir testi bir kapıya dönüştüren şeydir.
Bu alanda birçok araç bulunur ve her birinin gerçek güçlü yönleri vardır. Newman, Postman koleksiyonlarını komut satırından çalıştırır ve kutudan çıktığı haliyle CLI, JSON ve JUnit raporlayıcılarını destekler. Hurl, düz metin HTTP dosyalarını çalıştırır ve hafif, sürüm kontrollü kontroller için mükemmeldir. Prism, WireMock ve Mockoon'un CLI'si, iddia ağırlıklı test çalıştırmalarından ziyade sahteleme ve taslak oluşturmaya yöneliktir. Doğru seçim, sözleşmelerinizin halihazırda nerede yaşadığına bağlıdır.
Apidog nerede devreye giriyor?
Apidog CLI, başsız test yürütmesidir. apidog run komutu, herhangi bir GUI dahil olmadan test senaryolarını, senaryo klasörlerini, test paketlerini veya yerel dışa aktarılmış dosyaları çalıştırır. Bu da onu CI/CD, zamanlanmış işler ve bir geçiş veya başarısızlık gerektiren herhangi bir boru hattı aşaması için doğal bir uyum haline getirir.
Başsız temel öğeleri doğrudan kapsar:
- Veri odaklı test. Bir testi birçok giriş satırı üzerinde yinelemek için bir CSV veya JSON dosyasıyla
-d(veya--iteration-data) geçirin ve yineleme sayısını ayarlamak için-nkullanın. - Raporlayıcılar. Rapor türlerini seçmek için
-rkullanın. Varsayılanlar arasındacli,htmlvejsonbulunur, böylece konsola yazdırabilir ve aynı çalıştırmada bir HTML raporu yazabilirsiniz, örneğin-r html,cli. - Ortamlar ve dallar. Aynı testlerin hazırlık ve üretim ortamlarını kapsamasını sağlamak için bir çalıştırmayı
-eile belirli bir ortama veya--branchile bir proje dalına yönlendirin.
Tasarım bağlantısı, bunu çıplak bir çalıştırıcıdan ayıran şeydir. Apidog ile, başsız çalıştırdığınız testler, tasarladığınız, belgelediğiniz ve taklit ettiğiniz aynı sözleşmeden gelir. Belirtimden uzaklaşan ayrı bir koleksiyon yoktur. Apidog'un sahte sunucusunu CI'da da çalıştırabilirsiniz, böylece gerçek bağımlılık var olmadan önce bir tüketici sahte bir bağımlılığa karşı test edilebilir. Komutu uçtan uca görmek için, Apidog CLI kılavuzu tam bir çalıştırmayı adım adım açıklar.
Yapay zeka yerel bir açısı da var. Apidog'un MCP sunucusu, bir yapay zeka ajanı veya Cursor veya Claude gibi bir IDE'nin API belirtimlerinizi doğrudan okumasına ve onlarla çalışmasına olanak tanır, bu da bir ajan testleri oluştururken veya sürdürürken ve bu testler daha sonra başsız çalıştırıldığında kullanışlıdır. Apidog MCP istemcisiyle görsel hata ayıklama hakkındaki yazı, bu bağlantının pratikte nasıl çalıştığını gösteriyor.
Sıkça sorulan sorular
Başsız API testi, otomatik test ile aynı mıdır?
Örtüşüyorlar ama aynı değiller. Otomatik test, bir testin her adımı bir kişi tarafından tetiklenmeden çalışması anlamına gelir. Başsız API testi, yürütme yolunda GUI bulunmayan otomatik testtir. Çoğu modern otomatik API testi başsızdır, çünkü otomasyonun en temiz yolu ekranı bırakmak ve her şeyi bir komuttan yönlendirmektir.
Başsız test yapıyorsam hâlâ bir GUI aracına ihtiyacım var mı?
Genellikle evet, farklı bir iş için. Bir GUI, bir isteği tasarladığınız, bir yanıtı incelediğiniz ve yeni bir şeyi hata ayıkladığınız yerdir. Bir test kararlı hale geldiğinde, onu her derlemeyi koruyan başsız bir çalıştırmaya dönüştürürsünüz. Birçok ekip uygulamada tasarım yapar ve boru hattında yürütür, bu da komut satırından Apidog CLI testi'nin arkasındaki modeldir.
Başsız test CI/CD'ye nasıl uyar?
Başsız bir çalıştırıcı bir çıkış kodu döndürür, bu nedenle sıfır olmayan bir sonuç derlemeyi başarısız kılar. Çalıştırmayı bir boru hattı aşaması olarak eklersiniz, doğru ortama yönlendirirsiniz ve birleştirmeleri ve dağıtımları engellemesine izin verirsiniz. Bu, herhangi bir manuel adım olmadan CI'da API testleri çalıştırmanın temel mekanizmasıdır.
Başsız test, sahte API'leri de kapsayabilir mi?
Evet. Gerçek arka uç hala geliştirilirken bir sahte sunucuya karşı testler çalıştırabilirsiniz, bu yaygın bir API sahteleme modelidir. CI'da çalışan başsız bir sahte, canlı bağımlılık var olmadan önce bir ön ucun veya bir tüketici hizmetinin sözleşmeyi doğrulamasına olanak tanır.
Özetliyor
Başsız API testi, ekransız test etmektir: sözleşme odaklı, terminalde çalışan, makine tarafından okunabilen ve CI için yapılmış. API'lerin gerçekten nasıl tüketildiği ve modern ekiplerin nasıl gönderim yaptığıyla eşleşir. API ürün olduğunda, başsız test, ürünü her commit'te çalışır durumda tutmanın yoludur.
Denemek isterseniz, Apidog'u indirin, API'nizi tasarlayın veya içe aktarın ve apidog run ile testlerinizi başsız çalıştırın. Tasarladığınız aynı sözleşme, boru hattınızı koruyan testlere güç verir, hepsi Apidog'dan.