TDD (Test Driven Development) Nedir ?

Test Güdümlü Geliştirme yani TDD son yıllarda çokça duyduğumuz ve yaygınlaşmaya başlayan bir pratik. Temelde söylediği şey uygulama kodunu yazmadan önce testinin yazılması gerektiğidir. Yazılıma yeni başlayan biri için adapte olması başlangıçta çok zordur. Ama geleneksel yöntemlerle yazılım geliştirmeye alışkın olan biri için adapte olması çok daha zordur :)

Peki neden önce testleri yazmak gerek? "Önce kodu yazsak sonra testleri yazsak olmaz mı? Hem stopper da olmamış olur, uygulama test ortamında iş birimleri tarafından test edilirken biz de arkadan birim testleri yazarız ne olacak ki?" gibi düşünebilirsiniz. Ben de size direnç mekanizmanız iş başında derim.

Bu testlerin önce yazılması sadece bir sıralama meselesi değildir. Testleri düşünürken siz üzerinde çalıştığınız feature üzerine daha fazla düşünme şansı yakalarsınız. Yani alelade bir yazılım prosesi değildir testler. Günlük hayatta gelen işler çoğunlukla acildir. Ve bu aciliyet ve yoğunluktan işleri hakkıyla yazmak yerine, sadece gereksinimi karşılamak üzere hızlıca yazar ve devreye alırız. Ama bir süre sonra bu özensiz yazılmış kodlar uygulamayı tıkar bir bakmışsınız uygulama genişleyemez hale gelmiş. Yada canlıya 1 haftada çıktığınız bir ürün için 2 hafta canlıya hata desteği verirsiniz. Bunların çoğu da yazılım hatası yada eksiğidir. Yazılımı geliştirirken hep mutlu senaryo dediğimiz happy-path'lere göre yazmışızdır. Ama ürün canlıya çıktığında bir süre edge-case yani uç senoryo yaşanır. Ve çoğu durumda da validasyonlar eksiktir. Teknik borçlar boğazımıza kadar dayanmadan aksiyon almamız gerekir.

Yukarıda bahsettiğim senorya tahmin edilenden çok daha yaygın yaşanan bir senoryodur. Çözmenin ise tek ve basit bir yolu var. O da ilgili feature üzerine daha fazla düşünmek. Kod penceresini ilk değil en son açmak. Yazacağımız ürün ile düşünce aşamasında daha fazla zaman geçirmeliyiz. İşte TDD yaklaşımı tam olarak bunu yapabilmemiz için bize alan açar. Testleri düşünürken genelde uç senoryaları düşünürüz. Kodu yazarken bu kodu nasıl yazarım, gereksinimi nasıl karşılarım diye düşünürken, test yazarken bu feature'da olması gerekenlerle birlikte olmaması gerekenleri kodu patlatabilecek senoryoları da düşünürüz. İşin güzel tarafı bu zorlama değil içgüdüsel de bir yaklaşımdır. Kodu görmeden testi yazmak başlangıçta insanı çok zorlayabiliyor ama aradaki farkı gördükten sonra vazgeçilebilecek bir fayda değil :)

TDD'deki akışa daha yakından bakalım. Önce uygulama yada özelliğin tüm testleri yazılır. Doğal olarak tüm testler başlangıçta hata alacaktır çünkü kodları yoktur. Daha sonra adım adım kodlar yazılır. Kodlar tamamlandıkça testlerin bazıları geçmeye başlar. Kodlar tamamlandığındaysa tüm testlerin hatasız bir şekilde çalışıyor olması beklenir. Hata varsa koda dönüp yeniden refaktor yapılmalıdır. Sonra tüm testler yeniden çalıştırılmalıdır. Burda önemli olan nokta testlerin tümüyle ilgilenmek. Yazmış olduğumuz kod bir testin geçmesini sağlarken başka bir testin fail etmesine neden olabilir.

Ben TDD'nin bir yazılım geliştirme pratiğinden çok bir kültür meselesi olduğu görüşündeyim. Şirket genelinde yayılmadığı ve içgüdüsel olarak uygulanmadığı sürece zorlama bir pratik olarak kalmaya devem edecektir.

TDD'nin ne olduğunu az çok anladık. Biraz da nerden geldiğine bakalım istiyorum. TDD ilk olarak Kent Beck adında bir yazılımcı tarafından agile proje geliştirme metodoljisi olan extreme programming çatısı altında kullanıldı. Yazılım dünyasına ilk duyurulduğunda adından da anlaşılacağı üzere çok extreme bulunduğu için yaygın kullanılamadı. Hala günümüzde çok yaygınlaşabildiği söylenemez. Ama faydası da tartışılamaz. O nedenle günlük hayatımıza adapte edip bir prensip haline getirmek gerekiyor. Tam da bu nedenden ötürü TDD bir kültür meselesidir.

Okuma Önerisi: Test Driven Development ile ilgili daha detay bilgi sahibi olmak için tıklayınız.

İnceleme Önerisi: TDD'yi ilk öne süren kişi olan Kent Beck'in makalelerini incelemek ve test first yaklaşım ile ilgili daha detay bilgi sahibi olmak için tıklayınız.