Test güdümlü geliştirmeyi anlatmak kolay, uygulamak zordur. Kitaplar size temiz bir döngü öğretir: önce test, sonra kod, sonra refactor. Gerçek işte döngü; toplantılar, acil hatalar ve yarına yetişmesi gereken bir sürümle yarışır. Bu yazı, TDD'nin gündelik aksamda nasıl hayatta tutulduğunu, hangi tavizlerin verilebileceğini ve hangilerinin asla verilmemesi gerektiğini konuşuyor.

Kırmızı gerçekten kırmızı mı?

İlk disiplin, testin gerçekten çalıştığını görmektir. Yeni bir kural eklerken önce testi yazın, çalıştırın, kırmızı gördüğünüzden emin olun. Kırmızı görmeden yeşile geçen ekip, hiç başarısız olmayan testin peşinde yürür; test geçer ama kod hâlâ yanlıştır. Bu, TDD'nin en sessiz ve en pahalı tuzağıdır.

// Kırmızı: davranış henüz yok
it("3 saniyeden hızlı gönderimi reddediyor", () => {
  const karar = zamanTuzagı({ acilma: 100, gonderim: 1500 });
  expect(karar.kabul).toBe(false);
});

Yeşile geçişte en kısa yolu yazın. Zekice genellemeyi sonra yapın; refactor adımı sizin genellemenize aittir ve döngünün parçasıdır. Üçüncü adımı atlamayan ekip, testleriyle büyüyen bir borç biriktirir.

Sabır, disiplinden daha önemli

İkinci ders, döngüyü büyütmemektir. Bir geliştiricinin "önce bütün modülü test edeyim" hevesi, akşama kalmaz testi bırakmasına yol açar. Küçük adım atın: beş dakikada kırmızı, beş dakikada yeşil. Döngü uzadıkça geri bildirim gecikir, geciken geri bildirim ise TDD'nin bütün avantajını buharlaştırır. Kırmızıyı gördüğünüzde durun; yeşile geçmek için gerekenden fazlasını yazmayın.

Üçüncüsü, mevcut koda dokunurken bile ilk testi yazmaktır. Hata düzeltmede kural basittir: hatayı yeniden üreten testi yaz, kırmızıyı gör, sonra düzelt. Böylece aynı hata ikinci kez geri gelmez ve test bir belgeye dönüşür. Yeni katılan bir geliştirici, ilk haftasında bir hatayı bu yöntemle düzelterek hem kod tabanını hem ekibin dilini öğrenir.

Ekip ritmine oturtmak

TDD, bireysel bir alışkanlık gibi başlar ama ekip ritmine bağlanınca değer üretir. Kod inceleme listesinin ilk maddesi "testi okudun mu" olmalı. Pull request açıklamasında davranışın testte nereye yazıldığına yer verin; inceleyen kişi, davranışı koddan önce testte görsün. Böylece test, teslimatın bir parçası olur, sonradan eklenen bir yük değil.

Ekipte direnç olacaktır: "test yazmadan da düzgün kod yazılıyor" itirazı meşrudur ve cevabı da nettir — düzgün kod yazılıyor olabilir, ama altı ay sonra hâlâ düzgün çalıştığını kim kanıtlıyor? Test, bugünün değil yarının güvenme aracıdır.

Bir de ölçülebilir kazanç vardır: TDD yapan ekip, hata ayıklamaya harcadığı süreyi kendi ölçer. Kırmızı-yeşil döngüsünde hata, kod yazıldığı dakikada yakalanır; testsiz akışta ise üç gün sonra, başkasının commitsinde, bir müşteri kaydıyla birlikte ortaya çıkar. İki senaryonun toplam maliyetini hesaplayan ekip, tartışmayı kapatır.

Son söz: TDD teslimi geciktirmez, beklenmedik hataları teslimden önceye taşır. Sabır burada bir erdem değil, ölçülebilir bir mühendislik pratiğidir. Döngüyü küçük tutun, kırmızıyı ciddiye alın, refaktörü ihmal etmeyin. Gerisi ritim.