REST Assured ile API test otomasyonu: yazım, yapı ve bakım

REST Assured nedir, ne zaman tercih edilir?

REST Assured, resmî sitesinde REST servislerini test etmek ve doğrulamak için bir Java kütüphanesi olarak tanıtılır; Ruby ve Groovy gibi dillerdeki yalın kullanımı Java dünyasına getirmeyi hedefler. Testler HTTP isteğini kurup yanıtı doğrulayan, okunması kolay bir söz dizimiyle yazılır. Resmî sitedeki örnekte bir uç noktaya istek atılır ve yanıtın durum kodu ile gövde alanları kontrol edilir.

Kütüphane, uygulama Java ile geliştirildiğinde ve ekip testleri aynı dil ve araç zinciri içinde (derleme aracı, test çerçevesi, sürekli entegrasyon) tutmak istediğinde doğal seçimdir. Arayüzden bağımsız olarak servis katmanını doğrudan sınadığı için tarayıcı testlerine göre daha hızlı ve kararlıdır. Postman gibi grafik arayüzlü araçlar keşif ve elle denemede güçlüdür; REST Assured ise testlerin kodla yazılıp sürüm kontrolünde yaşadığı, otomasyonun ana hedef olduğu durumlarda öne çıkar.

Bir API testinin anatomisi

Her API testi şu parçalardan oluşur: isteğin kurulması, çağrının yapılması ve yanıtın doğrulanması. İstek tarafında adres, yol ve sorgu parametreleri, başlıklar, gövde ve kimlik bilgisi tanımlanır. Çağrıdan sonra yanıtın durum kodu, başlıkları ve gövdesi incelenir. Resmî sitedeki örnekte when ve then ile durum kodu ve gövde doğrulamaları zincirlenir; yanıt gövdesindeki alanlara JSON ya da XML yol ifadeleriyle erişilir.

İyi bir test şunları sınar: • Durum kodu: başarı, geçersiz girdi, yetkisizlik, bulunamama gibi durumlarda doğru kod dönüyor mu? • Gövde: doğru alanlar, doğru türler ve beklenen değerler var mı? • Başlıklar: içerik türü, önbellek ve güvenlik başlıkları doğru mu? • Yan etki: bir kayıt oluşturan çağrıdan sonra kayıt gerçekten okunabiliyor mu?

Bir testin başarısız olduğunda neyi, neden doğruladığı anlaşılmalıdır; bu yüzden test adı davranışı anlatmalı, tek test tek davranışı sınamalıdır.

Şema doğrulama ve sözleşme kontrolü

Alan değerlerini tek tek kontrol etmek kırılgandır ve yeni alan eklendiğinde fark edilmez. Şema doğrulaması, yanıtın yapısını bir sözleşmeye göre denetler: hangi alanlar zorunlu, türleri ne, iç içe yapı nasıl? REST Assured sürümlerinin haberlerinde JSON Schema desteğinin gelişimi izlenebilir; kullandığınız sürümde desteklenen şema sürümünü belgelerden kontrol edin.

Sözleşme kontrolü, tüketici ve üretici ekipler arasındaki uyumu korumak içindir. Servis yanıtının yapısı bilinçsiz değişirse, onu tüketen uygulamalar çöker. Şemayı testlerle birlikte sürümlemek ve her değişiklikte çalıştırmak, kırıcı değişiklikleri üretime çıkmadan yakalar.

Dikkat edilecek nokta, şemanın aşırı katı ya da aşırı gevşek olmamasıdır. Her opsiyonel alanı zorunlu kılmak testi gereksiz kırılgan yapar; hiçbir şeyi zorunlu kılmamak ise doğrulamayı anlamsızlaştırır. Gerçekten sözleşmenin parçası olan alanlar zorunlu işaretlenmelidir.

Kimlik doğrulama, senaryo zincirleri ve veri odaklı testler

Gerçek API'ler genellikle korumalıdır. Kimlik doğrulama testlerinde hem başarılı girişin hem de geçersiz, süresi dolmuş ve yetkisiz kimlik bilgilerinin davranışı sınanır. Jeton alma adımı tek bir yardımcı metotta toplanır, testler bu metodu çağırır; kimlik bilgileri koda gömülmez, ortam yapılandırmasından okunur.

Senaryo zincirleri, birbirine bağlı çağrıları sınar: sipariş oluştur, siparişi oku, güncelle, sil. Bir çağrının yanıtından alınan kimlik, sonraki çağrıda kullanılır. Zincirleri kısa tutun ve her testin kendi verisini kurup temizlemesini sağlayın; testler arası sıra bağımlılığı hataları gizler ve paralel çalışmayı imkânsız kılar.

Veri odaklı testlerde aynı test mantığı farklı girdi kümeleriyle çalıştırılır: geçerli ve geçersiz e-posta biçimleri, sınır değerleri, boş alanlar gibi. Girdi tablosu test kodundan ayrılır, yeni durum eklemek yalnız veri satırı eklemek olur. Örneğin bir kayıt servisinde çok sayıda geçersiz girdi biçimini tek test metodu ve bir veri tablosu karşılar.

Yapılandırma, yeniden kullanım ve bakım

Test sayısı arttıkça kopyala-yapıştır en büyük bakım yükü olur. Ortak adres, başlıklar ve kimlik doğrulama bir kez tanımlanır ve tüm testlerce paylaşılır; bir değişiklik tek yerden yapılır. Ortam adresleri (geliştirme, test, hazırlık) yapılandırma dosyasından gelir, böylece aynı testler farklı ortamlarda koşar.

Bakım için şu pratikler işe yarar: • İstek kurma, yanıt okuma ve doğrulama için küçük yardımcı sınıflar yazın; testleri ince tutun. • İstek ve yanıt gövdelerini sınıflara eşleyin; metin biçiminde elle JSON üretmek hataya açıktır. • Hata durumunda isteği ve yanıtı günlüğe yazdıracak şekilde yapılandırın; hata ayıklama süresini kısaltır. • Beklenen değerleri sabitlere ve yapılandırmaya taşıyın; sihirli değerler okunabilirliği bozar. • Kararsız (bazen geçen bazen kalan) testleri hemen inceleyin; kökünde sıklıkla veri bağımlılığı ya da zamanlama vardır.

Performans, raporlama ve CI entegrasyonu

API testleri sürekli entegrasyon hattında her değişiklikte çalıştığında değer üretir. Testler komut satırından çalıştırılabilir olmalı, sonuçlar standart bir raporda toplanmalı ve başarısız test birleştirmeyi engellemelidir. Raporlarda yalnız geçti/kaldı değil, başarısız isteğin ayrıntısı da yer almalıdır.

Hız için testler bağımsız olmalı ki paralel çalışabilsin. Yavaş testler (uzun akışlar) ayrı bir kümeye alınıp daha seyrek çalıştırılabilir. Temel yanıt süresi kontrolleri eklenebilir, ancak asıl yük ve dayanıklılık testi için ayrı yük test araçları kullanılır; REST Assured bu işin aracı değildir.

Örneğin bir ekip, her çekme isteğinde hızlı bir 'duman' kümesi (kritik uç noktalar) çalıştırır; gece ise tam küme koşar. Böylece geri bildirim hızlı kalır, kapsam da korunur.

Sık yapılan hatalar ve öğrenme yolu

Sık görülen hatalar: • Yalnız durum koduna bakmak. Başarı kodu dönen ama yanlış veri taşıyan yanıt testi geçirir. • Testleri sıraya bağımlı yazmak, ortak veriyi paylaştırmak. • Kimlik bilgilerini ve adresleri koda gömmek. • Yalnız mutlu yolu sınamak; hata, yetkisizlik ve sınır değerleri atlanır. • Gerçek ortamda silici testler çalıştırmak ya da veriyi temizlememek. • Her ayrıntıyı doğrulayıp testleri kırılgan yapmak.

Öğrenme yolu olarak önce HTTP temellerini (yöntemler, durum kodları, başlıklar) ve JSON yapısını öğrenin. Sonra tek bir uç noktaya basit bir test yazın, ardından kimlik doğrulamalı akışlara, şema doğrulamaya ve veri odaklı testlere ilerleyin. Son aşamada ortak yapılandırma, raporlama ve CI entegrasyonu gelir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

API Test Otomasyonu (REST Assured) programı modül başlıklarına göre REST Assured temellerini, şema doğrulama ve sözleşme kontrolünü, kimlik doğrulama ve yetki senaryolarını, senaryo zincirleri ve veri odaklı testleri, yapılandırma, yeniden kullanım ve bakımı, performans, raporlama ve CI entegrasyonunu kapsar.