TDD (Test Driven Development) konuşulurken genelde aynı şeyler söylenir:

• Daha güvenli kod
• Refactor kolaylığı
• Daha az bug
• Daha temiz mimari

Bunların hepsi doğru.

Ama bence TDD’nin en büyük faydası çok daha farklı bir yerde.

Ve ilginç şekilde çoğu ekip bunun farkında bile değil.

Yazılımın en büyük gizli maliyeti

Bir yazılım projesinde en büyük zaman kaybı çoğu zaman kod yazmak değildir.

Asıl maliyet şudur:

Developer’ın aklında kalan soru işaretleri.

Çünkü gerçek hayatta geliştirilen sistemler genelde tam net değildir.

Örneğin feature açıklaması şöyle gelir:

• Kullanıcı ödeme yapabilmeli
• Sipariş iptal edilebilmeli
• İade süreci desteklenmeli

Ama gerçek problem burada başlar.

Developer’ın kafasında onlarca soru oluşur:

• İade edilmiş sipariş tekrar aktif olabilir mi?
• Ödeme başarısız olursa sistem ne yapacak?
• Aynı anda iki istek gelirse ne olacak?
• Kullanıcı yetkisi değişirse davranış nasıl olacak?
• Edge case’lerde sistem nasıl davranacak?

Ve işin en tehlikeli kısmı şudur:

Bu soruların büyük kısmı çoğu zaman hiç sorulmaz.

Developer bazı şeyleri varsayar, PM başka bir şey düşünür, QA farklı bir davranış bekler.

Ve sonunda klasik cümle gelir:

“Ben sistemi böyle istememiştim.”

Problem şudur:

Kod çalışıyordur. Ama yanlış davranıyordur.

Üstelik artık çok geçtir.

Çünkü sistemin büyük kısmı çoktan geliştirilmiştir.

TDD’nin asıl gücü burada başlıyor

TDD’nin görünmeyen gücü, test yazarken sistemi geliştirmeden önce düşünmeye zorlamasıdır.

Çünkü test yazarken şunları netleştirmek zorunda kalırsın:

• Sistem ne yapmalı?
• Ne yapmamalı?
• Hangi durumda hata vermeli?
• Hangi edge case’ler desteklenmeli?
• Beklenen davranış tam olarak ne?

Aslında test yazımı sırasında sistemin kontratı oluşur.

Ve bu aşamada:

developer, PM, analyst, QA

aynı davranış üzerinde düşünmek zorunda kalır.

Bu yüzden iyi bir TDD süreci sadece teknik bir süreç değil, aynı zamanda bir clarification sürecidir.

Kod yazmadan önce sistemi simüle etmek

Birçok ekip doğrudan implementation’a başlar.

Ama TDD yaklaşımında önce davranış tanımlanır.

Bu çok büyük bir farktır.

Çünkü developer artık:

• Ne geliştireceğini
• Sistemin nasıl davranacağını
• Hangi edge case’lerin önemli olduğunu

önceden bilir.

Bu da yazılım geliştirmedeki en büyük gizli maliyetlerden birini azaltır:

Sürekli clarification ihtiyacı

TDD sadece test değildir

Birçok ekip TDD’yi yanlış anlıyor.

TDD’nin amacı sadece:

• test coverage artırmak
• bug azaltmak
• CI pipeline çalıştırmak

değildir.

TDD’nin asıl değeri şudur:

Sistemin davranışını implementation’dan önce netleştirmek.

Bu netlik ise:

• daha az yanlış geliştirme
• daha az geri dönüş
• daha az tartışma
• daha az yeniden iş
• daha az mental yük

anlamına gelir.

Çünkü developer artık sürekli:

“Acaba burada ne isteniyor?”

diye düşünmez.

Sonuç

Yazılımda en büyük zaman kayıplarından biri kod değil, belirsizliktir.

TDD bu belirsizliği azaltır.