Test Driven Development (T.D.D.)
Testin Yönlendirdiği Geliştirme
1. Kaynaklar
2. Tanım
Kod geliştirmeden önce testlerini yazarsanız, göreceksiniz ki kodu oluşturmanız çok daha kolay ve hızlı olacak. Bir birim testi oluşturmak ve testin geçmesini sağlayacak kodu yazmanın toplamı, sadece kodu doğrudan yazmanız ile neredeyse aynı zamanı alacak. Ancak zaten birim testleriniz varsa, kodu yazdıktan sonra onları oluşturmak için zaman harcamayacaksınız ve daha sonrası için daha da fazla zaman kazanacaksınız.
Bir birim testi oluşturmak, geliştiricinin ne yapılması gerektiğini gerçekten düşünmesine yardımcı olur. Gereksinimler testlerle sıkı bir şekilde baştan sabitlenmiştir. Çalıştırılabilen kod formunda yazılan bir spesifikasyon konusunda yanlış anlaşılma olamaz.
Ayrıca, çalışırken anında geribildirim de alırsınız. Bir geliştiricinin gerekli işlevi geliştirmesinin tamamlanıp tamamlanmadığı konusunda genelde bir belirsizlik vardır. Olası genişletmeler ve hata durumları da düşünüldüğünde gerekli kapsamın aşılması (scope creep) durumu oluşabilir. Ancak birim testlerimizi önce yazarsak, ne zaman bitirdiğimizi biliriz; tüm birim testleri geçer.
Önce testi geliştirmenin sistem tasarımı için de bir yararı vardır. Genelde bazı yazılım sistemlerinin birim testlerini oluşturmak zordur. Bu sistemlerin genelde önce kodları, sonra testleri yazılır, sıklıkla da tamamen başka bir takım tarafından. Testleri önce yazarak, müşterinize değer katacak her şeyi test etme arzusundan etkilenen bir tasarımınız olacaktır. Tasarımınız daha kolay test edilecek şekilde oluştuğundan, bu isteği yansıtır hale gelecektir.
Testin yönlendirdiği yazılım geliştirmenin bir ritmi vardır. Önce elimizdeki sorunun küçük bir görünümü hakkında bir test oluştururuz. Sonra testin geçmesini sağlayacak en basit kodu yazarız. Sonra ikinci bir test oluştururuz. Sonra bu yeni testin de geçmesini sağlayan kodu ekleriz, ama daha fazlasını değil! Üçüncü bir testimiz olana kadar daha fazlasını yazmayız. Geçecek test kalmayıncaya kadar devam ederiz.
Oluşturacağınız kod kısa ve öz olacak, sadece istediğiniz özellikleri sağlayacak. Diğer geliştiriciler testleri inceleyerek bu yeni kodu nasıl kullanacaklarını öğrenecekler. Sonuçları tanımlanmamış girdiler bariz bir şekilde test suitinde yer almayacaklar.
Testin yönlendirdiği geliştirmenin sonucunda bizim için sunduğu en önemli özellik olan Refactoring - Yeniden Düzenleme süreci devreye girer. Bu süreç istenildiği kadar uygulanabilir.
Sonuç olarak Testin Yönlendirdiği Geliştirmeyi (TDD) basit kod yazmamızı, basit tasarım yapmamızı ve düzenli olarak refactoring yapmamızı sağlayan bir pratik olarak özetleyebiliriz.
3. Testin Yönlendirdiği Programlama Ritmi
İşlevi geliştirmeden önce işlevin testini yaz.
Testi çalıştır ve testin geçmediğini (kırmızı çubuk) gör.
Sadece testin geçmesini sağlayacak kadar uygulama kodu yaz. Testin geçtiğini (yeşil çubuk) gör.
Kodu düzenle (Refactoring - Yeniden Düzenleme)
Tekrar başa dön.
4. Geleneksel Geliştirme vs. Testin Yönlendirdiği Geliştirme
Geleneksel geliştirme Geleneksel geliştirme alttan üste (bottom to top) bir yaklaşım sergiler. Bu tür geliştirme aşağıdaki sırayı izler:
Beklenen davranışa odaklanılmadığından, daha ziyade implementasyon detayları üzerinden ilerlendiğinden Y.A.G.N.I. (You're Not Gonna Need It) durumu yaşanması olasıdır. Genelde fazladan kod, fazladan test, gereksizce karmaşık tasarım oluşur. Bunlar da Clean Code - Temiz Kod düşmanlarıdır.
Testin yönlendirdiği geliştirme Testin yönlendirdiği geliştirme ise üstten alta (top to bottom) yaklaşımı benimser. Yani işlevlerin geliştirilmesinde aşağıdaki sıra izlenir:
Bu yaklaşım K.I.S.S. (Keep It Simple Stupid) prensibini uygulamayı sağlar. Sadece gerektiği kadar geliştirme yapılır, sadece gerektiği kadar test oluşur ve tasarım da buna göre basit olur.
5. Testin Yönlendirdiği Geliştirme Yaşam Döngüsü
Last updated
