Test Odaklı Geliştirme (TDD): Önce Test, Sonra Kod

İlk duyduğunuzda kulağa ters gelir: Kodu yazmadan önce, o kodun testini yazmak. Test edilecek bir şey yokken test nasıl yazılır? İşte test odaklı geliştirmenin (Test-Driven Development, TDD) sihri tam olarak buradadır. Testi önce yazdığınızda, aslında yazacağınız kodun ne yapması gerektiğini net bir sözleşme olarak tanımlarsınız. Kod, bu sözleşmeyi yerine getirmek için var olur.

TDD sadece bir test yazma tekniği değil, bir tasarım disiplinidir. Kodunuzu daha modüler, daha az bağımlı ve gelecekteki değişikliklere daha dayanıklı hale getirir. Bu yazıda TDD'nin ünlü döngüsünü, avantajlarını ve pratikte nasıl uygulanacağını ele alacağız.

Kırmızı-Yeşil-Yeniden Düzenle Döngüsü

TDD'nin kalbinde üç adımlı, sürekli tekrarlanan bir döngü vardır:

1. Kırmızı (Red): Henüz var olmayan davranış için bir test yazın. Test doğal olarak başarısız olur.
2. Yeşil (Green): Testi geçirecek en basit kodu yazın. Zarif olması gerekmez, sadece çalışsın.
3. Yeniden düzenle (Refactor): Testler yeşilken kodu temizleyin, iyileştirin. Testler yeşil kaldığı sürece güvendesiniz.

Bu döngü, dakikalar içinde tekrarlanır. Her tur, çalışan ve test edilmiş küçük bir davranış parçası ekler. Kod tabanınız adım adım, her adımı doğrulanmış bir şekilde büyür.

Basit Bir Örnek

Diyelim ki bir sepet tutarına indirim uygulayan bir fonksiyon yazacağız. TDD ile önce testi yazarız:

public function testYuzdeIndirimUygulanir()
{
    $sonuc = indirimUygula(100.0, 10);
    $this->assertEquals(90.0, $sonuc);
}

Bu test başarısız olur çünkü indirimUygula henüz yoktur. Şimdi testi geçirecek en basit kodu yazarız:

function indirimUygula(float $tutar, float $yuzde): float
{
    return $tutar - ($tutar * $yuzde / 100);
}

Test yeşile döner. Ardından ek durumları (sıfır indirim, geçersiz yüzde, negatif tutar) yeni testlerle ekler, her seferinde kodu genişletiriz. Böylece fonksiyon, kenar durumlarıyla birlikte sağlam biçimde olgunlaşır.

TDD'nin Getirdiği Kazanımlar

TDD ilk başta yavaşlatıyormuş gibi hissettirir, ama uzun vadede ciddi kazançlar sağlar:

• Güvenli değişiklik: Kapsamlı testler sayesinde kodu korkmadan yeniden düzenleyebilirsiniz.
• Daha iyi tasarım: Test edilebilir kod yazmak, sizi doğal olarak gevşek bağlı (loosely coupled) modüller kurmaya zorlar.
• Yaşayan dokümantasyon: Testler, kodun ne yaptığını anlatan güncel örneklerdir.
• Daha az hata: Kenar durumları geliştirme anında düşünülür, üretimde değil.

TDD'nin en büyük hediyesi cesarettir. İyi bir test ağı olduğunda, altı ay önce yazdığınız koda dokunmaktan korkmazsınız; testler sizi tutar.

TDD Ne Zaman Zorlaşır?

TDD her durumda mutlak bir kural değildir. Bazı senaryolarda uygulaması zorlaşır:

• Deneysel, tam olarak ne yapacağınızı bilmediğiniz keşif kodunda.
• Kullanıcı arayüzünün görsel detaylarında; burada başka test türleri devreye girer.
• Dış sistemlere yoğun bağımlı, test için taklit (mock) kurmanın pahalı olduğu yerlerde.

Bu durumlarda TDD'yi katı bir dogma olarak değil, elinizdeki araçlardan biri olarak görmek gerekir. Kritik iş mantığında TDD altın değerindeyken, geçici bir prototipte gereksiz yük olabilir.

Alışkanlık Haline Getirmek

TDD'nin en zor yanı, alışkanlığı edinmektir. İlk hafta doğal olmayan, yavaş bir süreç gibi gelir. Ancak birkaç hafta ısrar ettiğinizde, "önce test" düşünce yapısı içselleşir ve kod yazma şekliniz kalıcı olarak değişir. Berasoft'ta iş kritik modüllerde (ödeme hesaplamaları, sipariş durumu geçişleri, fiyatlandırma kuralları) TDD'yi standart olarak uygularız; çünkü bu alanlarda bir hatanın maliyeti çok yüksektir.

Sonuç

Test odaklı geliştirme, "önce test" gibi basit bir kuralın ardında derin bir tasarım felsefesi barındırır. Sizi, kodun ne yapması gerektiğini önce net biçimde tanımlamaya, ardından yalnızca gerekeni yazmaya iter. Kırmızı-yeşil-yeniden düzenle döngüsü, yazılımı küçük, doğrulanmış adımlarla büyütmenin en güvenli yoludur. TDD bir gümüş kurşun değildir; ama iş kritik kodda uyguladığınızda, size cesaret ve gönül rahatlığı kazandırır. Ve yazılımda gönül rahatlığı, paha biçilmez bir değerdir.