Test Kapsamı %90 Ama Hatalar Devam Ediyor: Metriğin Yalanı

Test kapsamı raporunda %90 görmek rahatlatıcıdır. Bu sayı yönetim sunumlarına girer, birleştirme kurallarına eşik olarak konur ve ekipte "test tarafı iyi durumda" hissi yaratır. Sonra üretimde art arda hatalar çıkar ve kimse neden yakalanmadığını anlamaz. Bu çelişkinin sebebi metriğin bozuk olması değil, ne ölçtüğünün yanlış anlaşılmasıdır.

Bu oran tam olarak neyi ölçer?

Satır kapsamı yalnızca tek bir şey söyler: bu satır, testler çalışırken en az bir kez çalıştırıldı. Söylemediği şey ise çok daha önemlidir: o satırın doğru sonucu ürettiği hiçbir yerde iddia edilmemiş olabilir. Aşağıdaki gibi bir test, ilgili fonksiyonun tüm satırlarını kapsar ve raporda mükemmel görünür — ama hiçbir şey doğrulamaz:

public function testHesaplamaCalisiyor(): void
{
    $sonuc = $this->hesaplayici->hesapla(100, 0.18);
    $this->assertNotNull($sonuc); // her değer bu testi geçer
}

Fonksiyon 118 yerine 1180 döndürse bu test yine yeşil kalır. Rapor ise ilgili satırların hepsini "çalıştırıldı" diye işaretler.

Yüksek oranın altındaki beş tipik boşluk

1. İddiası zayıf testler

Yukarıdaki örnekteki gibi assertNotNull, assertTrue(is_array(...)) türü kontroller oranı yükseltir, güveni yükseltmez. Sağlıklı bir testin iddiası, beklenen değeri açıkça yazar.

2. Yalnızca mutlu yolun test edilmesi

Hatalar nadiren normal akışta çıkar; sınırlarda çıkar. Boş liste, sıfır tutar, negatif değer, aynı anda gelen iki istek, zaman aşımına uğrayan servis... Testleriniz yalnızca beklenen senaryoyu içeriyorsa, yüzde yüksek ama risk aynen yerinde demektir.

3. Aşırı taklit (mock) kullanımı

Her bağımlılığı taklit ettiğinizde, testiniz gerçekte yalnızca kendi kurgunuzu doğrular. Veritabanı katmanı tamamen mock'lanmış bir testte, yanlış yazılmış bir sorgu asla yakalanmaz. Bu yüzden en az birkaç testin gerçek veritabanına karşı çalışması gerekir — özellikle sorgu performansı ve doğruluğu söz konusuysa; ilgili tuzaklar için N+1 sorgu problemi yazımıza bakabilirsiniz.

4. Kolay olanın test edilmesi

Sayısal bir hedef konulduğunda ekipler doğal olarak en kolay ölçülecek yerleri test eder: getter'lar, basit dönüştürücüler, yapılandırma sınıfları. Bunlar %90'ı getirir ama hiçbiri hata üretmeyen kod parçalarıdır. Asıl risk, karmaşık iş kurallarının bulunduğu ve kapsanması zor olan yerlerdedir.

5. Test verisinin gerçeği temsil etmemesi

Testlerde hep "Ahmet Yılmaz, 100 TL" kullanılırken üretimde Türkçe karakterli uzun isimler, kuruşlu tutarlar ve boş alanlar vardır. Veri çeşitliliği testlerde yoksa, o çeşitliliğin doğurduğu hatalar da yoktur.

Testlerinizi test etmek: mutation testing

Bu yanılgıyı ortaya çıkarmanın en doğrudan yolu mutation testing'dir. Araç, kodunuzda küçük bozmalar yapar — bir > işaretini >= yapar, bir + yerine - koyar, bir koşulu tersine çevirir — ve testlerinizi çalıştırır. Testler hâlâ yeşilse, o bozma "hayatta kalmış" demektir; yani o davranışı gerçekten doğrulayan bir testiniz yok.

Bu yöntemin sonucu genellikle sarsıcıdır: %90 satır kapsamı olan projelerde mutation skorunun %40'larda çıkması sık görülür. Aradaki fark, tam olarak testlerinizin ölçmediği risktir. PHP tarafında Infection, JavaScript'te Stryker gibi araçlar bu işi yapar. Tüm kod tabanında çalıştırmak yavaş olabileceği için, en kritik modülle başlamak makul bir stratejidir.

Bu metriği nasıl kullanmalı?

Ölçümü tamamen çöpe atmak da doğru değildir; yanlış olan tek başına hedef yapılmasıdır. Daha sağlıklı kullanım biçimleri:

• Ters yönde okuyun. "%90'a ulaşalım" yerine "kritik ödeme modülünde kapsanmayan satır kaldı mı?" diye sorun. Rapor, nerede hiç test yok sorusunun iyi bir cevabıdır; testler iyi mi sorusunun kötü bir cevabıdır.
• Eşiği düşüşe karşı kullanın. Mutlak bir hedef yerine, "yeni eklenen kodun kapsamı düşmesin" kuralı daha az oyunlaştırılabilir.
• Hata kayıtlarıyla eşleştirin. Üretimde çıkan her hatadan sonra sorun: bu hatayı yakalayacak test neden yoktu? Bu soru, herhangi bir yüzdeden çok daha iyi bir test stratejisi üretir.

Hangi testin hangi seviyede yazılacağına dair genel çerçeve için test piramidi yazımız, testlerin sürekli entegrasyona bağlanması için de CI/CD kurulumu yazımız tamamlayıcı okumalardır. Konunun kavramsal arka planı için Martin Fowler'ın test kapsamı üzerine notu kısa ve nettir.

Sonuç

Test kapsamı, kodunuzun ne kadarının çalıştırıldığını ölçen kullanışlı ama sınırlı bir araçtır; kalitenin kendisi değildir. Yüksek kapsamla birlikte devam eden hatalar, genellikle iddiası zayıf testlerin, test edilmemiş sınır durumlarının ve gerçeği temsil etmeyen test verisinin sonucudur. Bugün yapabileceğiniz en aydınlatıcı deney şudur: en kritik modülünüzde bir iş kuralını kasten bozun ve testleri çalıştırın. Testler hâlâ yeşilse, kapsam yüzdenizin ne anlattığını yeniden düşünmenin tam zamanıdır.