Test Odaklı Geliştirme (TDD), yazılımcıların önce birim testi yazıp başarısız olduğunu görmesi, ardından testi geçecek kodu geliştirmesi prensibine dayanır. Bu yaklaşım, kodun yeterli test kapsamına sahip olmasını ve hızlı geri bildirim döngüsü sunmasını amaçlar. Yazar, TDD'nin hızlı geri bildirim gibi bazı unsurlarını faydalı bulsa da, otomatik yazılım testi ve özellikle TDD etrafında oluşan "kült"e karşı her zaman şüpheci yaklaşmıştır. Birçok kişi TDD'ye sorgusuz bir sadakatle bağlanarak, bu fikir etrafında araçlar ve pratikler inşa etmektedir.
TDD'nin temel kusuru, her fonksiyon için test sağlamasına rağmen, kodu mümkün olduğunca "test edilebilir" olacak şekilde şekillendirmesidir; bu durum her zaman daha iyi koda yol açmaz. Dahası, TDD, testlerin doğruladığı davranışın yazılım için doğru davranış olduğunu garanti etmez. Binlerce geçen teste ve %100 test kapsamına sahip bir yazılım, gereksinimleri karşılamayabilir; bu kapsamlı testlere rağmen yanlış davranabilir. TDD, işinizde bir güven duygusu verse de, bu güven yerinde olmayabilir.
TDD kültü, sizi iyi ve özenli bir programcı gibi hissettirme yeteneğini kullanır. Hızlı geri bildirim döngüsü güçlü bir dopamin döngüsünü tetikler. Buna %100 kapsama hedefleme kültürü eklendiğinde, bir sayının yükseldiğini izlemekten ek bir haz alırsınız. Bu kültüre dahil olduğunuzda, yeşil kalacak yeni README rozetleri, harika grafikler ve sayılar gibi yüzeysel ödüller elde edersiniz. Tüm bu gösteriş, ekibinizin ulaşması gereken sonuçlara katkıda bulunmasa bile kendinizi iyi bir programcı gibi hissetmenizi sağlar. Bu gösterişli özellikler, işin gerçek kalitesinden bağımsız olarak iyi yazılım mühendisliği çalışmasının estetiğini benimsemenize olanak tanır.
Yazılım geliştirmede TDD gibi popüler metodolojilerin faydalarının yanı sıra, aşırı bağlılığın ve yüzeysel metriklerin gerçek proje başarısından uzaklaştırabileceği eleştirel bir bakış açısı sunuyor.