Bir kez çalışıp bir daha asla çalıştırılmayan bir API testi yazmaya değmez. Testin değeri tekrardan gelir: bir müşteri fark etmeden regresyonu yakalamak, bir yeniden düzenleme (refactor) sonrası bir sözleşmenin hala geçerli olduğunu kanıtlamak, yeşil onaylarla bir dağıtımı (deploy) engellemek. Bir API otomasyon test çerçevesi, bu tekrarı ucuz, güvenilir ve okunabilir kılan yapıdır.
Bu makale, bir API otomasyon test çerçevesinin gerçekte ne olduğunu, her ciddi çerçevenin içerdiği beş katmanı ve kendi çerçevenizi oluşturmak ile mevcut bir aracı benimsemek arasında seçim yapmaya yönelik pratik bir süreci açıklamaktadır. Tarayıcı veya birim testlerine değil, özellikle API testlerini otomatikleştirmeye odaklanmıştır, böylece ekibinizin sunduğu HTTP hizmetlerine doğrudan uygulayabilirsiniz.
API otomasyon test çerçevesi nedir
Bir çerçeve tek bir kütüphane değildir. Bir ekibin API testlerini bir kez yazıp isteğe bağlı olarak çalıştırmasına olanak tanıyan, üzerinde anlaşmaya varılmış bileşenler, kurallar ve 'yapıştırıcı kod' (glue code) kümesidir. Böyle bir çerçeve olmadan, her mühendis bir istek göndermek, bir yanıtı kontrol etmek ve test verilerini yüklemek için kendi yöntemini geliştirir. Testler çalışır, ancak birbirinden uzaklaşır, mantığı tekrarlar ve sürdürülemez hale gelir.
İyi bir çerçeve bu kararları ortadan kaldırır. İsteklerin nerede bulunduğunu, onaylamaların (assertions) nasıl yazıldığını, test verilerinin nereden geldiğini, bir raporun neye benzediğini ve test paketinin sürekli entegrasyona nasıl bağlandığını tanımlar. Yeni testler, mevcut kalıbı yeniden icat etmek yerine onu takip eder. Tutarlılık asıl amaçtır: tek bir kişinin sürdürebileceği bir test paketi bir yüktür, oysa herhangi bir ekip üyesinin okuyup genişletebileceği bir test paketi bir varlıktır.
Çerçeveler iki ana şekilde gelir. Kod öncelikli (code-first) çerçeveler, ekibinizin zaten kullandığı bir dildeki kütüphanelerden (örneğin pytest ile Python veya Jest ile JavaScript) oluşturulur. Apidog gibi platform tabanlı çerçeveler, size aynı beş katmanı görsel bir arayüz aracılığıyla sunar, böylece altyapı kodunu yazmak yerine testleri yapılandırırsınız. Her ikisi de otomatik API testleri üretir. Fark, ne kadar 'yapıştırıcı koda' sahip olduğunuzdadır.
Her çerçevenin ihtiyaç duyduğu beş katman
İster kendi çerçevenizi kurun ister hazır bir çözüm alın, bir API otomasyon test çerçevesi aynı beş katmandan oluşur. Herhangi bir seçeneği bu listeye göre değerlendirin ve eksiklikler belirgin hale gelecektir.
1. İstek katmanı
Bu katman HTTP çağrıları gönderir ve yanıtı açığa çıkarır. Temel URL'leri, başlıkları, kimlik doğrulama belirteçlerini, sorgu parametrelerini, istek gövdelerini ve zaman aşımlarını yönetir. Kod öncelikli bir kurulumda bu, genellikle bir HTTP istemcisi etrafındaki ince bir sarmalayıcıdır, böylece testler tekrarlayan kalıp kodları (boilerplate) tekrar etmez. Temel tasarım hedefi, bir testin bir soket çağrısının nasıl oluşturulduğunu değil, ne istediğini açıklaması gerektiğidir. Temiz bir istek katmanı ayrıca yeniden deneme mantığını ve bağlantı havuzlamayı merkezileştirerek bireysel testlerin kısa kalmasını sağlar.
2. Onaylama (Assertion) katmanı
Bir istek göndermek hiçbir şeyi kanıtlamaz. Onaylama katmanı, yanıtın beklentileri karşılayıp karşılamadığını kontrol eder: durum kodu, yanıt süresi, başlıklar ve gövdenin şekli ve değerleri. Güçlü çerçeveler, yalnızca elle yazılmış alan kontrolleri yerine bir OpenAPI tanımına karşı şema doğrulamasını destekler, çünkü şema kayması en yaygın API kusurlarından biridir. Onaylama stratejisine daha derinlemesine bakmak isterseniz, API onaylamaları kılavuzumuz gerçek hataları yakalayan kalıpları kapsar.
3. Test verisi katmanı
Testlerin girdilere ihtiyacı vardır ve sabit kodlanmış girdiler hızla bozulur. Bu katman, fixture'lardan, factory'lerden, CSV veya JSON dosyalarından veya bir veritabanından veri sağlar. Ayrıca bu verilerin yaşam döngüsünü de yönetir: bir testten önce bir kullanıcı oluşturur ve sonrasında siler, böylece çalıştırmalar bağımsız ve tekrarlanabilir kalır. Bir test gövdesinin birçok girdi satırına karşı çalıştığı veri odaklı test (data-driven testing) burada yer alır. CSV ve JSON ile veri odaklı bir API testi yaklaşımı, yeni test fonksiyonları yazmadan kapsamı genişletmenizi sağlar.
4. Raporlama katmanı
Yalnızca bir çıkış kodu üreten bir test çalıştırmasının hata ayıklaması zordur. Raporlama katmanı hangi testlerin çalıştığını, hangilerinin başarısız olduğunu, her bir hata için isteği ve yanıtı, zamanlamayı ve çalıştırmalar arasındaki eğilimleri kaydeder. İyi raporlar, kırmızı bir derlemeyi bir saatlik tahminden ziyade beş dakikalık bir düzeltmeye dönüştürür. HTML raporları insanlara yardımcı olur; JUnit XML çıktısı CI sunucularının sonuçları satır içi göstermesine yardımcı olur.
5. CI entegrasyon katmanı
Son katman, test paketini pipeline'ınıza bağlar, böylece her commit, pull request veya programa göre testler otomatik olarak çalışır. Ortam seçimini, gizli enjeksiyonu, derlemeyi doğru şekilde başarısız eden çıkış kodlarını ve raporlar için yapıt yüklemesini yönetir. CI'da başsız (headless) çalışamayan bir çerçeve, yalnızca yarım bir çerçevedir. CI/CD pipeline'larındaki API testleri hakkındaki rehberimiz, bu katmanı nasıl temiz bir şekilde bağlayacağınızı gösterir.
Bir çerçeve ancak beş katmanın tamamı dengede kaldığında sağlıklıdır. Ekipler genellikle gerçek test gibi hissettiren istek ve onaylama katmanlarına aşırı yatırım yapar ve kararsız bir çalıştırma veya hata ayıklanamayan bir arıza yeniden oluşturmayı zorlayana kadar veri ve raporlamayı ihmal ederler. Beş katmanı, bir kerelik bir kurulum olarak değil, sürekli gözden geçireceğiniz bir kontrol listesi olarak ele alın. Yeni bir uç nokta eklediğinizde, yeni testin hangi katmana dokunduğunu ve o katmanın hala geçerli olup olmadığını sorun.
API otomasyon test çerçevesi ne değildir
Sınırlar konusunda kesin olmak faydalıdır, çünkü iki yaygın karışıklık zaman kaybına yol açar. Bir API otomasyon test çerçevesi bir yük testi aracı değildir. Fonksiyonel API testleri doğruluğu onaylar: doğru durum, doğru gövde, doğru davranış. Yük ve stres testleri, API'nin hacim altında dayanıp dayanmadığını doğrular ki bu, ayrı araçlarla ele alınan ayrı bir konudur. Bazı ekipler, fonksiyonel testlere gevşek zamanlama onaylamaları ekleyip buna performans kapsamı derler; bu doğru değildir. Gerçek yük çalışmaları için, API performans testi eğitimimizde açıklanan gibi özel bir yaklaşım kullanın.
Ayrıca birim testi (unit testing) ile aynı değildir. Birim testleri, genellikle bir ağ çağrısı olmaksızın, küçük kod parçalarını izole bir şekilde kontrol eder. API testleri, yönlendirme, serileştirme, kimlik doğrulama ve veri katmanı dahil olmak üzere çalışan hizmeti HTTP üzerinden test eder. Her ikisi de sağlıklı bir test stratejisinde yer almalı, ancak farklı kusurları yakalar ve çerçevenin farklı bölümlerinde bulunur. Bunları tek bir etiket altında karıştırmak, üretime kadar kimsenin fark etmediği boşluklara yol açar.
Kod öncelikli ve platform tabanlı: bir karşılaştırma
Dürüst takas kontrol ve hız arasındadır. Kod öncelikli çerçeveler size tam esneklik sunar ve uygulama kodunuzla birlikte yaşar, ancak her katmanı kendiniz sürdürürsünüz. Platform tabanlı çerçeveler size beş katmanı da anında sunar, ancak bu, aracın modeli içinde çalışma maliyetiyle gelir.
| Faktör | Kod öncelikli çerçeve | Platform tabanlı çerçeve |
|---|---|---|
| Kurulum süresi | Günler ila haftalar süren yapıştırıcı kod | Dakikalar |
| Esneklik | Sınırsız, kodlayabileceğiniz herhangi bir mantık | Platform tarafından sınırlı |
| Bakım sahibi | Ekibiniz | Çoğunlukla satıcı |
| Oryantasyon | Dil bilgisi gerektirir | Görsel, düşük bariyer |
| Şema doğrulama | Kütüphaneyi kendiniz eklersiniz | Genellikle yerleşik olarak gelir |
| En uygun | Güçlü mühendislik kapasitesine sahip ekipler | Karma ekipler, hızlı teslimat |
Birçok ekip her ikisini de kullanır. Mühendisler karmaşık, mantık ağırlıklı senaryolar için kod öncelikli bir paket tutarken, QA ve ürün ekibi bir platformda geniş bir kapsam oluşturur. İkisi birbiriyle çelişmez; aynı yüzeyin farklı kısımlarını kapsarlar.
Bir çerçeve nasıl seçilir veya benimsenir
En popüler seçeneği seçmek yerine kısa, sıralı bir süreç kullanın.
- API'lerinizi envanterleyin. Hizmetleri sayın, protokolleri (REST, GraphQL, gRPC, SOAP) not edin ve en çok risk taşıyan uç noktaları belirleyin. Bu size istek ve onaylama katmanlarının neyi desteklemesi gerektiğini söyleyecektir.
- Ekibinizi değerlendirin. Bir Python mühendisleri ekibi kodsuz bir araca zorlanmamalıdır ve bir analist ekibine boş bir pytest deposu verilmemelidir. Çerçeveyi, testleri kimin yazıp sürdüreceğine göre eşleştirin.
- CI uyumluluğunu kontrol edin. Çerçevenin başsız (headless) çalıştığını, doğru çıkış kodlarını döndürdüğünü ve pipeline'ınızın anladığı bir rapor formatı yayınladığını doğrulayın. Bunu elli test yazıldıktan sonra değil, ilk günden test edin.
- Tek bir gerçek hizmet üzerinde pilot uygulama yapın. Mevcut bir API için on anlamlı test yazın. Bu pilot uygulamadan herhangi bir özellik kontrol listesinden daha fazlasını öğreneceksiniz.
- Bir veri stratejisine karar verin. Test paketi büyümeden önce testlerin verileri nasıl alacağını ve temizleyeceğini seçin, çünkü yüz teste veri yönetimini sonradan eklemek zahmetlidir.
Somut seçenekleri karşılaştırmak isterseniz, en iyi otomatik test platformları listemiz onları yan yana sıralar ve daha geniş kapsamlı otomasyon test çerçevesi kılavuzumuz hepsinin altındaki yapısal kalıpları açıklar.
Bu aşamada sık yapılan bir hata, bir pilot uygulamadan ziyade bir özellik listesine göre seçim yapmaktır. Özellik listeleri en çok onay kutusuna sahip aracı ödüllendirir, ancak gerçekte istediğiniz araç, en yaygın testinizi yazmayı kolaylaştıran ve en yaygın hatanızı hata ayıklamayı kolaylaştıran araçtır. Bu nitelikler ancak gerçek mühendisler gerçek bir hizmete karşı gerçek testler yazdığında ortaya çıkar. Bir pilot uygulama sırasında yapılan on dürüst test, bir haftalık satıcı karşılaştırmalarından daha fazlasını size söyleyecektir.
Apidog nerede devreye giriyor
Apidog, 'yapıştırıcı kod' olmadan beş katmanı sağlayan hepsi bir arada bir API platformudur. İstek katmanı, tasarım ve hata ayıklama için kullandığınız aynı uç nokta tanımlarını yeniden kullanır, böylece testler API ile senkronize kalır. Onaylama katmanı, görsel kontrolleri ve OpenAPI spesifikasyonunuza karşı şema doğrulamasını içerir. Veri odaklı çalıştırmalar için test verileri CSV veya JSON dosyalarından sürüklenebilir. Raporlar otomatik olarak HTML olarak oluşturulur ve CLI çalıştırıcısı Jenkins, GitHub Actions ve diğer CI sistemleriyle entegre olur.
Tasarım, hata ayıklama, mocklama ve test etme tek bir doğruluk kaynağını paylaştığı için, bugün hata ayıkladığınız bir istek, birkaç tıklamayla yarın bir regresyon testi haline gelir. Bu sıkı döngüyü elle bir araya getirilmiş bir yığınla yeniden üretmek zordur. Apidog'u indirebilir ve aynı öğleden sonra çalışan bir API test paketi oluşturabilirsiniz. Kodu tercih eden ekipler için Apidog, kod öncelikli paketinizin test ettiği API'leri tasarlamak ve mocklamak için hala yardımcı olur.
Sıkça sorulan sorular
Bir API test aracı ile bir API otomasyon test çerçevesi arasındaki fark nedir?
Bir araç istek gönderir ve yanıtları gösterir. Bir çerçeve yapı ekler: onaylamalar, test verileri, raporlama ve CI entegrasyonu için paylaşılan kurallar, böylece testler tekrarlanabilir ve büyük ölçekte sürdürülebilir olur. Birçok modern platform her ikisidir, tek bir üründe geçici hata ayıklama ve tam bir otomasyon çerçevesi sunar.
Bir API otomasyon test çerçevesini kullanmak için kod yazmayı bilmem gerekiyor mu?
Hayır. pytest gibi kod öncelikli çerçeveler programlama gerektirir, ancak platform tabanlı çerçeveler görsel bir arayüz aracılığıyla otomatik API testleri oluşturmanıza ve çalıştırmanıza olanak tanır. Ekibinizin becerilerine göre seçiminizi yapın. Karma ekipler genellikle her ikisini de kullanır; mühendisler kod öncelikli pakette, diğerleri ise platformda çalışır.
Beş katmandan kaçını atlayabilirim?
Hiçbirini, ancak bazıları minimal olabilir. Küçük bir paket bile istek gönderme, yanıtları kontrol etme, veri sağlama, sonuçları görme ve CI'da çalışma yöntemine ihtiyaç duyar. CI katmanını atlamak en yaygın hatadır ve bu, otomatik testleri sessizce manuel testlere dönüştürür.
API testlerinin kararsız (flaky) olmasını nasıl engellerim?
Kararsızlık genellikle paylaşılan durumdan ve yönetilmeyen test verilerinden kaynaklanır. Her testin kendi verisini oluşturmasını ve temizlemesini sağlayın, test yürütme sırasına bağımlılıktan kaçının ve güvenilmez bağımlılıklar için kararlı ortamlar veya mocklar kullanın. Sağlam bir test veri katmanı, çoğu kararsızlığı başlamadan önce önler.
API testleri bir OpenAPI şemasına göre doğrulamalı mı?
Evet, bir spesifikasyonunuz olduğu her zaman. Şema doğrulama, elle yazılmış onaylamaların sıklıkla gözden kaçırdığı yeniden adlandırılmış bir alan veya değişmiş bir tür gibi yapısal kaymaları yakalar. Ayrıca testleri sözleşmeyle otomatik olarak senkronize tutar, böylece API geliştikçe onaylama katmanı bozulmaz.