Test Güdümlü Geliştirme (Test Driven Development - TGG), bağımlılıkların azaltılmasını zorlamaya ve yazılımın tasarımının gerçekleştirilmesine yarayan otomatikleştirilmiş birim testlerinin kullanıldığı gelişmiş bir tekniktir. Teknik üzerinde, “çevik (agile) geliştirme” yöntemleri kullanan geliştiriciler yoğun bir şekilde durmaktadır.

Genel olarak test yöntemleri başta ve sonda olmak üzere iki türlüdür. Testin sonda yapılması klasik yöntemdir. Kod yazılır ve sonunda testler (unit test) yapılır. TGG’nin temelini ise testi başa almak oluşturur. Kod yazılmadan testler yazılır, test geçilirse kodlamaya girilir. Burada önemli olan “Testi Geçebilecek Kadar Kod Yazma” durumudur ve eşli programlamada belirtilen esaslarla uyum içinde çalışılır. Genel olarak bir TGG döngüsü şu şekilde verilebilir:

 

• Çalışılan özellik, hikâye vs. için gereksinimler anlaşılır (Use Case diyagramları ve Kullanıcı Hikâyeleri/Kartları -User Stories- ).
• Test yazılmaya başlanır, tüm testler çalıştırılır ve varsa hatalar görülür. Bu yeni test, “öngörülen” bir sebepten ötürü de başarısız olabilir. Burada testin kendisini test edilir ve negatif test olarak adlandırılır. Bir özelliğin başarılı olması beklenen kısmı olabileceği gibi başarısız olması beklenen kısımları da bulunur ve bu başarısız olması beklenen kısımlar da negatif test ile test edilir. “Çalıştığından emin ol, kırılması (break) için bir değişiklik yap ve kırılsın” şeklinde güzel de bir özeti vardır. :)
Bu aşama çalıştırılan test programında (Junit, Nunit, VSTS Test Project vs) kırmızı renkle sonuçlanır. (Yani test hataları vardır dolayısıyla bu renkle gösterilir)
• Testi geçebilecek kadar kod yazılır. Tabii burada yazılan kod mükemmel veya iyi tasarlanmış olmak zorunda değildir. Önemli olan testi geçebilmesidir. Daha ileri ve test edilmemiş değişikliklere bakılmaması gerekir. (YAGNI: You Ain’t Gonna Need It) terimi gerekli olmayan işleri veto etmede kullanılır. Eğer yeni bir işlevsellik gerekiyorsa o zaman bir başka teste gereksinim var demektir.
Bu aşama çalıştırılan test programında (Junit, Nunit, VSTS Test Project vs) yeşil renkle sonuçlanır
• Test geçilmişse, her şeyin çalıştığından emin olmak için bu noktaya kadar geçen tüm testler çalıştırılabilir.
• Kod yeniden düzenlenir (Refactoring). Tüm testlerden hala geçildiğinden emin olmak kaydıyla; tasarımı geliştirmek için bu zamana kadar geçen tüm testlerdeki kodlarda bulunan tekrarlar kaldırılır, tüm projeyi geliştirecek tasarım değişiklikleri yapılır. Her yeniden düzenleme sonrasında hala geçtiklerinden emin olmak için tüm testle yeniden çalıştırılır.
• Döngü bu şekilde devam ettirilir.

TGG’nin Sağladığı Yararlar
• Yüksek Kalitede Kod (Yazılım Ürünü) Oluşur.
• Yazılımın Doğru Çalıştığının Kanıtıdır.
• Öğrenmek için çok iyi bir yöntemdir.
• Refactoring yardımıyla tasarımı parçalanmadan geliştirme imkânı sunar.
• Birim testleri, örnek kod gibidir. (Örneğin kullanımını bilmediğiniz bir sınıf var ve kodun yazarı işten ayrılmış. Kendisine nasıl çalıştığını soramayacağımızdan birim testleri örnek kod gibi kullanılabilir.)
• Kodlamadan önce plan yapmayı sağlar. İlk soracağınız soru “Hangi kodu yazacağım?” olmamalı, “Bu problemi çözdüğümü nasıl bileceğim?” olmalıdır.
• Büyük Problemleri Küçük Parçalara Böler.
• Her Test Döngü Sonucu Geribildirimlere İmkân Tanır.

TGG’nin Engelleri
• Girişilen işte zamanla isteklerin değişmesi testlerin gözden geçirilmesi veya yeniden yazılmasını gerektirebilir.
• Proje zamanının tutturulamaması riski nispeten fazladır.

Görüldüğü gibi XP pratiklerinden biri olan Test Güdümlü Programlama hakkında bilgi vermeye çalıştım. Önümüzdeki yazılarda bu pratikler hakkında yazmaya devam edeceğim. Saygılar...

Referanslar
Extreme Programming Explained, Erich Gamma. Addison Wesley
Teach Yourself Extreme Programming In 24 Hours, Stewart Baird. SAMS
http://en.wikipedia.org/wiki/Extreme_Programming
http://www.extremeprogramming.org/rules/unittests.html

 

 İletişim : Bu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır