Test piramidi: otomatik testleri katmanlara dağıtma modeli

Test piramidi nedir?

Test piramidi (test pyramid), otomatik test çabasının hangi katmanlarda ne yoğunlukta yapılması gerektiğini anlatan bir modeldir. Şekil bir piramit olarak çizilir: tabanda çok sayıda küçük ve hızlı test, ortada daha az sayıda entegrasyon ya da servis testi, tepede ise az sayıda ama kapsamlı arayüz ve uçtan uca testler bulunur.

Modelin mesajı basittir: Testi ne kadar kullanıcıya yaklaştırırsanız o kadar yavaş, kırılgan ve maliyetli hale gelir. Bu yüzden hataların büyük kısmını mümkün olan en alt katmanda yakalamaya çalışmak gerekir. Kavramı çevik yazılım geliştirme literatürüne Mike Cohn'un taşıdığı kabul edilir.

Katmanlar ve her birinin görevi

• Birim testler (taban): Tek bir fonksiyonu ya da sınıfı, dış bağımlılıklarını taklit ederek (mock) sınar. Milisaniyeler içinde çalışır, hata nerede olduğunu doğrudan gösterir.
• Entegrasyon ya da servis testleri (orta): Bileşenlerin birlikte çalışmasını, örneğin uygulama kodunun veritabanıyla ya da bir API'nin başka bir servisle konuşmasını doğrular. Daha yavaştır, ortam kurulumu gerekir.
• Arayüz ve uçtan uca testler (tepe): Gerçek bir kullanıcı akışını tarayıcı ya da mobil uygulama üzerinden baştan sona dener. Kapsamı geniştir, ancak yavaştır ve arayüz değiştikçe sık kırılır.

Alttan üste doğru geri bildirim süresi uzar, bakım maliyeti artar, ama sistemin bütünüyle ilgili güven de artar. Piramit bu dengeyi kurmayı hedefler.

Nasıl çalışır? Bir örnek

Örneğin bir e-ticaret sepet modülünü düşünelim. İndirim hesaplayan fonksiyonun birçok girdi kombinasyonu vardır: kupon süresi dolmuş mu, sepet tutarı sınırı aşıyor mu, aynı ürüne birden fazla indirim uygulanabilir mi. Bu kuralların hepsi birim testle saniyeler içinde denenebilir.

Orta katmanda, sepet servisinin gerçek bir test veritabanıyla birlikte doğru kayıt oluşturup oluşturmadığı sınanır. Tepede ise yalnızca birkaç kritik akış arayüzden test edilir: ürünü sepete ekle, ödeme adımına geç, sipariş onayını gör. Bu şekilde ana kullanıcı yolu korunur, ama her indirim kuralını yavaş tarayıcı testiyle denemeye gerek kalmaz.

Ters piramit ve dondurma külahı anti-deseni

Birçok ekipte piramit tersine döner. Birim test yazma alışkanlığı zayıf olduğu için kalite güvencesi ağırlıklı olarak arayüz testiyle yapılır. Sonuç, uzun süren, sık kırılan ve neden başarısız olduğu zor anlaşılan bir test paketidir. Bu duruma dondurma külahı (ice cream cone) anti-deseni denir.

Belirtiler: her kod değişikliğinde test paketinin uzun sürmesi, aralıklı başarısız olan (flaky) testler, hata çıktığında kaynağın bulunmasının uzaması ve ekibin testlere güvenmeyip elle kontrole dönmesi. Çözüm, arayüz testlerinin bir kısmını alt katmana indirmek ve yeni özellikte birim testi baştan yazma alışkanlığı kurmaktır.

Modelin sınırları ve alternatifleri

Test piramidi bir reçete değil, yön gösteren bir sezgidir. Her proje için aynı oranlar geçerli değildir. Çoğunlukla mikroservis mimarisinde servisler arası sözleşmeleri sınayan testler daha önemli hale gelir; bu nedenle bazı ekipler piramit yerine daha geniş bir orta katmanı olan farklı şekiller (ör. kupa ya da bal peteği benzeri modeller) önerir.

Tüm bu modeller aynı ilkeye dayanır: hızlı geri bildirim veren testlere ağırlık ver, pahalı testleri seçici kullan. Karar verirken yalnızca şekle bakmayın; hangi hataların nerede yakalandığını ve testlerin ne kadar sürede çalıştığını ölçün.

Piramidi uygulamak için pratik adımlar

• Mevcut testleri katmanlarına göre sınıflandırıp dağılımı görünür hale getirin.
• Arayüz testinde doğrulanan bir kuralı alt katmanda test edebiliyorsanız onu aşağı taşıyın.
• Aralıklı başarısız olan testleri ya düzeltin ya da paketten çıkarın; güveni zedeleyen test, testsizlikten kötüdür.
• Regresyon paketini katmanlı ve öncelikli kurun, hızlı testleri her kod gönderiminde, yavaş testleri daha seyrek çalıştırın.
• Hata çıktığında önce o hatayı yakalayacak en alt katmandaki testi yazın.

Bu alışkanlıklar test paketini hem hızlı hem de güvenilir tutar.

Mindset programlarında test stratejisi

Test Otomasyonu ve QA Temelleri programı test türlerini, kapsam yönetimini ve test otomasyon temellerini ele alır. Test Driven Development (TDD) ve Unit Testing programı birim test, mocking ve test izolasyonu üzerinde çalışır. Regresyon Test Otomasyonu Stratejisi katmanlı paket tasarımı ve önceliklendirmeyi, Appium programı ise mobil arayüz testlerini kapsar.

Geliştirici ve QA ekiplerinin ortak bir test stratejisi dili kurması isteniyorsa bu içerikler birbirini tamamlar: geliştiriciler alt katmana, test mühendisleri üst katmana odaklanırken piramit ortak referans olur.