Test-Driven Development

Felsefe

Temel ilke: Testler davranışı public interface'ler üzerinden doğrulamalı, implementasyon detaylarından değil. Kod tamamen değişebilir; testler değişmemeli.

İyi testler entegrasyon tarzındadır: real kod yollarını public API'ler üzerinden çalıştırırlar. Sistemin ne yaptığını, nasıl yaptığını değil, anlatırlar. İyi bir test bir specification gibi okunur - "user geçerli cart ile checkout yapabilir" tam olarak hangi kabiliyetin var olduğunu söyler. Bu testler refactor'ları survive ederler çünkü iç yapıya umursamazlar.

Kötü testler implementasyona bağlıdır. Internal collaborator'ları mock ederler, private method'ları test ederler, veya external araçlar üzerinden doğrularlar (örneğin interface'i kullanmak yerine doğrudan database sorgulama). Uyarı işareti: test refactor yaptığında kırılır ama davranış değişmemiş. Eğer internal bir function'ı rename ettiğinizde testler fail olursa, bu testler implementasyonu test ediyordu, davranışı değil.

Örnekler için tests.md'ye ve mocking yönergeleri için mocking.md'ye bak.

Anti-Pattern: Horizontal Slices

YAPMAYINIZ tüm testleri önce yazıp, sonra tüm implementasyonu yazınız. Bu "horizontal slicing" - RED'i "tüm testleri yaz" ve GREEN'i "tüm kodu yaz" olarak almak.

Bu çöp testler üretir:

• Toplu yazılan testler hayal edilen davranışı test eder, gerçek davranışı değil
• Sonunda şeylerin _şekli_ni test edersiniz (data structure'lar, function signature'ları) user-facing davranıştan ziyade
• Testler gerçek değişikliklere duyarsız hale gelir - davranış kırıldığında pass eder, davranış iyiyken fail eder
• Headlight'larınızı aşarsınız, implementasyonu anlamadan test structure'a commit etmiş olursunuz

Doğru yaklaşım: Tracer bullet'lar via vertical slices. Bir test → bir implementasyon → tekrarlayın. Her test önceki döngüden öğrendiklerinize cevap verir. Kodu az önce yazdığınız için, tam olarak hangi davranışın önemli olduğunu ve nasıl doğrulanacağını bilirsiniz.

YANLIŞ (horizontal):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

DOĞRU (vertical):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

İş Akışı

1. Planlama

Codebase'i keşfederken, proje'nin domain glossary'sini kullanın ki test isimleri ve interface vocabulary'si projenin diline uygun olsun, ve dokunduğunuz alandaki ADR'lere saygı gösterin.

Herhangi bir kod yazmadan önce:

• [ ] User ile ne interface değişikliklerinin gerekli olduğunu onaylayın
• [ ] User ile hangi davranışları test edeceğinizi onaylayın (önceliklendir)
• [ ] Deep modules için fırsatları belirleyin (küçük interface, derin implementasyon)
• [ ] Testability için interface'leri tasarlayın
• [ ] Test edecek davranışları listeleyin (implementasyon adımlarını değil)
• [ ] User onayını plana alın

Sorun: "Public interface neye benzemeli? Hangi davranışlar test etmek için en önemli?"

Her şeyi test edemezsiniz. User ile tam olarak hangi davranışların en önemli olduğunu onaylayın. Test çabasını kritik yollar ve karmaşık logic'e odaklayın, her olası edge case'e değil.

2. Tracer Bullet

SİSTEM hakkında BİR şeyi doğrulayan BİR test yazın:

RED:   İlk davranış için test yaz → test fail eder
GREEN: Geçirmek için minimal kod yaz → test pass eder

Bu sizin tracer bullet'ınız - yolun end-to-end çalıştığını kanıtlar.

3. İnkremental Loop

Kalan her davranış için:

RED:   Sonraki test yaz → fail eder
GREEN: Geçirmek için minimal kod → pass eder

Kurallar:

• Bir test anda
• Sadece mevcut testi geçirmek için yeterli kod
• Gelecek testleri öngörmeyin
• Testleri observable davranışa odaklı tutun

4. Refactor

Tüm testler pass ettikten sonra, refactor adaylarına bakın:

• [ ] Duplication'ı extract edin
• [ ] Module'ları derinleştirin (complexity'yi basit interface'lerin arkasına taşıyın)
• [ ] SOLID ilkelerini doğal yerlere uygulayın
• [ ] Yeni kodun existing kod hakkında neler ortaya çıkardığını düşünün
• [ ] Her refactor adımından sonra testleri çalıştırın

RED iken asla refactor yapmayınız. Önce GREEN'e ulaşın.

Her Döngü İçin Checklist

[ ] Test davranışı anlatır, implementasyonu değil
[ ] Test sadece public interface kullanır
[ ] Test internal refactor'ı survive ederdi
[ ] Kod bu test için minimal
[ ] Spekulatif feature eklenmedi