Servis sanallaştırma ile test ortamı bağımlılıkları nasıl çözülür?

Servis sanallaştırma hangi sorunu çözer?

Bir uygulamayı test etmek için çoğu zaman o uygulamanın konuştuğu başka sistemlere de ihtiyaç duyarsınız: ödeme sağlayıcısı, kimlik doğrulama servisi, başka bir ekibin geliştirdiği API, mainframe üzerindeki bir müşteri kaydı, üçüncü taraf bir kargo servisi. Bu sistemler test sırasında ya henüz yazılmamıştır, ya başka bir ekibin test ortamında kilitlidir, ya her çağrıda ücret doğurur, ya da test verinizi bozacak biçimde ortak kullanılır.

Servis sanallaştırma bu bağımlılığın yerine, gerçek servisin yalnızca testiniz için gereken davranışını taklit eden bir sanal servis koymaktır. Sanal servis gerçek adrese benzer bir adreste dinler, beklediğiniz isteği tanır ve önceden tanımladığınız yanıtı döner. Test, karşısındakinin gerçek mi sanal mı olduğunu bilmez.

Sahte nesne (mock) yaklaşımından farkı kapsamındadır: mock genellikle tek bir kod sınıfının içinde yaşar ve birim testinde kullanılır. Servis sanallaştırma ise ağ üzerinden, HTTP gibi gerçek bir protokolle konuşan ayrı bir süreçtir. Bu yüzden uygulamanın tamamını, yapılandırma ve istemci kütüphaneleriyle birlikte uçtan uca test edebilirsiniz.

Önce hangi bağımlılığın sanallaştırılacağına karar verin

Her bağımlılığı sanallaştırmak gerekmez. Karar verirken şu soruları sorun:

• Bu servis test sırasında erişilebilir mi, yoksa başka bir ekibin ortamına mı bağlıyız?
• Çağrı yan etki üretiyor mu: gerçek para çekimi, e-posta gönderimi, stok düşümü gibi?
• Hata ve gecikme senaryolarını gerçek serviste isteğimiz an üretebiliyor muyuz?
• Servisin yanıtı test tekrarlanabilirliğini bozuyor mu, örneğin her çağrıda değişen zaman damgası ya da sıra numarası?

Bu soruların çoğuna olumsuz yanıt veriyorsanız sanallaştırma adayıdır. Kendi ekibinizin yönettiği, hızlı ve yan etkisiz bir veritabanı ise çoğunlukla gerçek haliyle kalmalıdır. Aksi hâlde, sanal servislerin ayakta tutulması test kodundan daha pahalı hâle gelir.

Pratik bir ayrım: kontrol edemediğiniz ve yavaş ya da riskli olan dış bağımlılıkları sanallaştırın, kontrol edebildiğiniz ve ucuz olan iç bileşenleri gerçek bırakın.

Adım adım: ilk sanal servisi kurmak

Sanal servis kurulumu şu sırayla ilerler:

• Gerçek servisin sözleşmesini toplayın: uç nokta adresi, yöntem, istek gövdesi, yanıt gövdesi, başlıklar, hata biçimleri. Belge yoksa gerçek servise bir kez çağrı yapıp yanıtı kaydedin.
• Hangi isteklerin testlerinizde gerçekten kullanıldığını listeleyin. Sanal servise yalnızca bunlar girer, gerçek servisin tüm yüzeyi girmez.
• Her istek için eşleştirme kuralı yazın: hangi yöntem, hangi yol, gerekirse hangi başlık ya da gövde alanı.
• Her kural için yanıt tanımlayın: gövde, başlıklar, durum kodu.
• Uygulamanızın ayarlarında dış servis adresini sanal servisin adresine çevirin. Bu adres koda gömülü değil, yapılandırmada olmalıdır; aksi halde sanallaştırma için kodu değiştirmek zorunda kalırsınız.
• Testi çalıştırın ve sanal servisin hangi isteği aldığını kayıtlardan doğrulayın. Eşleşmeyen istek varsa araçlar çoğunlukla bunu açıkça bildirir.

WireMock ile küçük bir örnek

WireMock, HTTP tabanlı servisleri taklit etmek için yaygın kullanılan açık kaynaklı bir araçtır. Resmî belgelerde gösterildiği biçimde, bir kuralı JSON dosyası olarak tanımlarsınız. Örneğin müşteri bilgisi dönen kurgusal bir uç nokta için:

{ "request": { "method": "GET", "urlPath": "/customer/example" }, "response": { "jsonBody": { "ad": "Ayşe" }, "headers": { "Content-Type": "application/json" } } }

Burada request bölümü hangi isteğin eşleşeceğini, response bölümü ne döneceğini anlatır. Yanıt gövdesini jsonBody alanına doğrudan JSON nesnesi olarak yazabilirsiniz, metne çevirmeniz gerekmez. Durum kodunu belirtmezseniz araç başarılı bir yanıt varsayar; hata senaryosu için durum kodunu açıkça yazarsınız.

Aynı kuralı Java testinin içinden de tanımlayabilirsiniz:

stubFor(get(urlEqualTo("/customer/example")).willReturn(aResponse().withHeader("Content-Type", "application/json").withBody("{\"ad\":\"Ayşe\"}")));

JSON dosyası ekip içinde paylaşmaya, kod tabanlı tanım ise testin kendi içinde okunur kalmasına uygundur. Hangisini seçerseniz seçin, sanal servis davranışı sürüm kontrolünde, testle aynı depoda durmalıdır.

Davranış modelleme: başarılı yanıt yetmez

Gerçek servisler her zaman düzgün yanıt vermez; sanal servisin asıl değeri de burada ortaya çıkar. Sanal servise şu davranışları öğretin:

• Gecikme: yavaş yanıt veren bir bağımlılık karşısında uygulamanın zaman aşımı ve yeniden deneme mantığı çalışıyor mu?
• Hata yanıtları: sunucu hatası, yetkisiz erişim, bulunamadı gibi durumlarda kullanıcı anlamlı bir mesaj görüyor mu, yoksa ekran boş mu kalıyor?
• Bozuk ya da eksik yanıt: beklenen alan gelmediğinde uygulama çöküyor mu?
• Bağlantının hiç kurulamaması: servis ayakta değilken uygulama nasıl davranıyor?
• Durumlu akış: ilk çağrıda sipariş yok, ikinci çağrıda var gibi. WireMock bunu belgelerinde durumlu davranış (stateful behaviour) başlığı altında anlatır.

Örneğin bir ödeme akışında yalnızca başarılı onayı test eden ekip, ödeme sağlayıcısı geç yanıt verdiğinde müşteriye çift sipariş oluşturan bir hatayı ancak canlıda fark eder. Sanal servisle bu senaryo her gün, dakikalar içinde tekrarlanabilir.

Test verisi, izolasyon ve sanal servisin güncel kalması

Sanal servis testlerinizi bağımsızlaştırır, ama kendi bakım yükünü getirir. Şu konulara baştan dikkat edin.

Test verisi: Her test kendi verisini bilmeli. Ortak bir sanal servise birden fazla test yazıyorsa, bir testin değiştirdiği durum diğerinin sonucunu etkilememelidir. Testten önce kuralları yükleyip sonra temizleyin ya da her test için ayrı bir sanal servis örneği başlatın.

İzolasyon: Sanal servisi konteyner olarak başlatmak, ekipteki herkesin ve sürekli entegrasyon hattının aynı ortamı almasını sağlar. Yerel makinedeki elle başlatılan sürece bağımlı testler başka makinede çalışmaz.

Güncel kalma: En büyük risk, gerçek servis değiştiği hâlde sanal servisin eski davranışı sürdürmesidir. Testler yeşil görünür, canlıda uyumsuzluk çıkar. Bunu azaltmak için sözleşme testleri (contract testing) kullanın: aynı sözleşmeyi hem sanal servise hem gerçek servise karşı periyodik olarak çalıştırın. Gerçek servis bir alanı değiştirdiğinde sözleşme testi bunu yakalar ve sanal servisi güncellemeniz gerektiğini gösterir.

Sık yapılan hatalar

Sanallaştırma projeleri genellikle teknik zorluktan değil, aşağıdaki alışkanlıklardan zayıflar.

• Her şeyi sanallaştırmak: ekip sanal servislerin bakımıyla uğraşır, testler gerçek sistemden kopar.
• Yalnızca mutlu yolu tanımlamak: hata ve gecikme senaryoları olmadan sanallaştırmanın en değerli yarısı kullanılmamış olur.
• Sözleşmeyi gerçek servisle hiç karşılaştırmamak: sanal servis zamanla bir kurgu hâline gelir.
• Adresi kodun içine gömmek: ortam değiştiğinde kod değiştirmek gerekir.
• Gerçek müşteri verisini yanıtlara kopyalamak: kişisel veri test ortamına taşınır. Yanıtlarda kurgusal veri kullanın.
• Sanal servis kurallarını sürüm kontrolü dışında tutmak: kimin ne zaman neyi değiştirdiği izlenemez.

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

Test Ortamı Sanallaştırma ve Servis Sanallaştırma eğitimi, test mühendisleri, kalite güvence ekipleri ve entegrasyon testinde bağımlılıkla boğuşan geliştiriciler için kurgulanmıştır. Modül başlıkları yöntemin akışını izler: sanallaştırmanın test stratejisindeki yeri, sanal servis tasarımı ve davranış modelleme, izole ortam ile test verisi ve sürdürülebilirlik.

Kurumsal ekipler için uygulanabilirliği, birden fazla ekibin ortak bir test ortamını paylaştığı yapılarda öne çıkar. Ortak ortam kuyruğu yerine her ekibin kendi sanal bağımlılıklarını yönetmesi, sürüm geçişlerinde ve entegrasyon testinde bekleme zamanını azaltmak isteyen ekipler için anlamlı bir çalışma alanıdır.