Yazılım Testi: Hangi Testi Ne Zaman Yazmalı?

Yazılım testi, çoğu ekipte "vaktimiz olursa yaparız" listesinde bekler ve o vakit hiç gelmez. Oysa testin amacı hata bulmak değildir; asıl amacı koda dokunabilme cesareti vermektir. Testi olmayan bir modülde altı ay sonra kimse refactor yapmak istemez, teknik borç birikir ve proje yavaşlar. Bu yazıda hangi testin ne zaman yazılacağını, sahadan örneklerle netleştiriyoruz.

Üç katman, üç farklı soru

Birim testi: "Bu hesap doğru mu?"

Tek bir fonksiyon veya sınıfı, dış bağımlılıklardan yalıtarak sınar. Hızlıdır, binlercesi saniyeler içinde çalışır. En yüksek getiriyi şurada verir: kıdem tazminatı hesabı, izin bakiyesi, KDV hesaplaması, indirim kuralları, tarih aralığı hesapları.

Örnek bir kabul kriteri doğrudan teste dönüşebilir: "Yıllık izin hakkı, 1-5 yıl kıdemde 14 gün; 5 yılı doldurduğu gün 20 güne çıkar." Bu cümle üç test demektir: 4 yıl, tam 5 yıl ve 6 yıl.

Entegrasyon testi: "Parçalar birlikte çalışıyor mu?"

Veritabanı, model ve servis katmanının birlikte doğru davranıp davranmadığını sınar. Kayıt oluşturma, ilişkili tabloların doğru güncellenmesi, işlem (transaction) bütünlüğü burada test edilir. Birim testlerinden yavaştır ama gerçek hataların çoğu bu katmanda yakalanır; çünkü sahadaki hatalar genelde tek fonksiyonda değil, parçaların birleşim yerinde çıkar.

Uçtan uca test: "Kullanıcı işini bitirebiliyor mu?"

Tarayıcı seviyesinde, gerçek akışı taklit eder: giriş yap, formu doldur, kaydet, listede gör. Yavaş ve kırılgandır; bu yüzden yalnızca kritik akışlar için yazılır. Bir e-ticaret için "sepete ekle → ödeme → sipariş oluştu", bir İK sistemi için "izin talebi → amir onayı → takvime işlenmesi" yeterlidir.

Doğru denge nasıl kurulur?

Klasik öneri piramittir: çok sayıda birim testi, orta sayıda entegrasyon testi, az sayıda uçtan uca test. Bunun tersine dönmesi (her şeyi tarayıcıdan test etmek) test paketini o kadar yavaşlatır ki ekip çalıştırmayı bırakır. Çalıştırılmayan test, olmayan testtir.

Pratik hedef: Tüm test paketi, geliştiricinin kahve almaya gitmesini gerektirmeyecek kadar hızlı olmalı. Bu sınır aşıldığında testler görmezden gelinmeye başlar.

Nereden başlamalı? Öncelik sırası

1. Para ve hak doğuran hesaplar: maaş, prim, fatura, izin, stok. Hata maliyeti doğrudan ölçülebilir.
2. Yetki kontrolleri: Bir kullanıcı başkasının kaydını görebiliyor mu? Bu testler güvenlik açığını erken yakalar.
3. Daha önce hata çıkmış yerler: Hata bir kez çıktıysa aynı bölgede tekrar çıkma ihtimali yüksektir.
4. Sık değişen kodlar: Sürekli dokunulan yerlerde test, değişikliğin bedelini düşürür.

İyi testin özellikleri

• Bağımsız: Testler birbirinin bıraktığı veriye güvenmemeli, her biri kendi verisini kurmalı.
• Deterministik: Bugün geçip yarın kalan test, güveni testlerin tamamından siler.
• Okunabilir: Test adı, neyin beklendiğini anlatmalı: izinBakiyesiBesYilDolduğundaYirmiGuneCikar.
• Tek şeye odaklı: Bir testte on iddia (assertion) varsa hangi kuralın bozulduğu anlaşılmaz.

Zamana ve rastgeleliğe bağlı testler

En sık kırılan testler tarihe bağlı olanlardır. "Bugünden 30 gün sonra" hesaplayan bir kod, ayın 31’inde beklenmedik sonuç verebilir. Çözüm, zamanı doğrudan sistemden okumak yerine dışarıdan verilebilir hâle getirmektir. Aynı ilke rastgele sayı ve dış servis çağrıları için de geçerlidir: test edilebilirlik, bağımlılığın dışarıdan verilebilmesiyle başlar.

Testleri otomatikleştirmek

Testin yazılması yetmez; her değişiklikte kendiliğinden çalışması gerekir. Sürüm kontrol sistemine bağlı bir hat (CI) kurulduğunda, hatalı kod ana dala girmeden fark edilir. Küçük ekiplerde bile bu, gözden kaçan hataların önemli bir bölümünü keser. Kavramın ayrıntıları için Martin Fowler’ın test piramidi yazısı hâlâ en iyi başvurulardan biridir.

Test verisi ve sahte nesneler

Testlerin en çok bakım yükü çıkaran kısmı veri hazırlığıdır. Her testte elle onlarca satır kayıt oluşturmak, kısa sürede okunamaz bir yapıya dönüşür. Çözüm, varsayılan değerlerle çalışan ve yalnızca teste özel alanları değiştiren fabrika (factory) yardımcıları yazmaktır.

Dış servislere yapılan çağrılar da testlerde gerçek olmamalıdır. Ödeme sağlayıcısına, e-posta sunucusuna veya harici API’ye giden istekler sahte nesnelerle değiştirilmelidir; aksi hâlde testler yavaşlar, internet kesildiğinde kırılır ve daha kötüsü, test çalıştırıldığında gerçek e-posta gönderilir. Ancak sahteleme aşırıya kaçarsa testler gerçek davranışı değil, kendi kurgunuzu doğrular hâle gelir; bu dengeyi entegrasyon testleriyle kurmak gerekir.

Hata çıktığında izlenecek yol

Üretimde bir hata bildirildiğinde sıra şudur: önce hatayı yeniden üreten bir test yazın (test kırmızı olmalı), sonra kodu düzeltin (test yeşile dönsün), en sonda benzer senaryoları da ekleyin. Bu disiplin, aynı hatanın altı ay sonra geri gelmesini engeller ve test paketinizi gerçek risklerin haritasına dönüştürür.

Sonuç

Test yazmak mükemmeliyetçilik değil, risk yönetimidir. Her satırı test etmeye çalışmayın; yanlış çalıştığında para, hak veya güven kaybettiren kodları test edin. Bu yaklaşım hem paketi hızlı tutar hem de asıl korunması gereken yerleri korur.