Baştan söyleyeyim. Test Driven Development (Test Odaklı Geliştirme) nefret ettiğim bir yaklaşımdır; ama ne yazık ki son iki yıldır ağırlıklı olarak ‘farkında’ bile olmadan kullandığım bir yaklaşım oldu. Hatta biraz daha derinlemesine incelediğimde, neredeyse 5 yıldır “yahu ben bunu yazdım ama şu kısım çalışmazsa hiçbir şey çalışmaz, önce ben bunu test edeyim” dediğimi farkettim.
Test Driven Development nedir ne değildir açıklamama gerek yok, yani bu yazıyı okuyorsanız konsepte hakimsinizdir diye tahmin ediyorum; ama yine de kısaca özet geçmek gerekirse, Test Odaklı Geliştirme, geliştirme sürecini küçük parçalara bölerek her adımda isteninen işlevselliği test edip çalıştığına emin olduktan sonra bir sonraki aşamaya geçmektir. Bunun otomasyonu Unit Test konusu altında incelenebilir; ama konumuz o değil.
Tabi burada bahsettiğim yüksek seviyeli dillerin Exception Handling sistemlerinin ardına sığınmak değil.
Daha açık konuşmak gerekirse bahsettiğim şöyle bir şey değil:
[java]decimal ParseDecimal(string value){
try {
return Decimal.Parse(value);
} catch {
return -1;
}
}[/java]
veya çok daha kolayına ve tembelliğe kaçıp exception’ı sistem kendisi halletsin:
[java]public static DateTime Parse(string input){
return DateTime.Parse(input);
}[/java]
Burada exception handling’i yerden yere vurma gibi bir amacım yok, bilâkis, kullanılması ve tahşidatının yapılması gereken bir yaklaşım. Ama bazen öyle bir kod yazarsınız ki ne istediğiniz gibi çalışır ne de exception’ı handle edilir. Try Catch burada tek kurtarıcınız olabilir.
Ama bunlar hep Test Driven Development. Benim gibi paranoyaklaştığınızda, ya da halihazırda çalışan bir sisteme bir şey eklemeye ya da bir şeyi değiştirmeye kalkıştığınızda işler değişiyor. En basidinden Paralycid’in kodlarını yazarken.
Adımlar:
1) Önce normal runtime sırasında karşılaşılmayacak ve çağırılmayacak bir fonksiyonu (en kompleks haliyle) yazıyoruz. Bu, Paralycid’te olan bir özellik olarak ‘Güvenlik kamerasının numarasını tuşladığımızda arayarak bağlanmak ve kamera görüntüsünü ekrana yansıtmak’ olabilir.
2) Şimdi bunun her adımında ‘şöyle olması gerekiyor’ dediğiniz her yere konsol çıktısı kodu ekliyoruz. Mesela numara girildiğinde numarayı doğru algılama, kamera listesi içerisinde numaraya göre arama, varsa/yoksa kısmına girme, yok ise yanlış numara girildiğine dair cevap, var ise bağlanmaya çalışma vs. vs…
3) Profiler veya Debugger, ne kullanıyorsanız artık ona göre çalıştırıp breakpoint’ler ile adım adım devam etmek.
4) Exception handling’i her türlü exception’ı handle edebilecek hale getirme
5) Fonksiyonu neredeyse hiçbir zaman exception handle etmek zorunda bırakmadan düzenleme
6) Tekrar 1.
Bir sonraki adımda kameranın telefona görüntü göndermesi diyerek aynı adımları tekrarlayarak tek bir özelliği adım adım debug ederek sisteme eklemiş oluyoruz.
Tabi benim bu noktaya gelmemde “İlk compile sırasında çalışıyorsa, kesinlikle yanlış bir şeyler vardır, hem de çok yanlış şeyler” olayını defalarca yaşamış olmam olabilir; ama artık en basit karşılaştırma işlemlerinde bile debug edecek bir satır olmadan kodun ve dolayısıyla projenin bir sonraki aşamasına geçemiyorum 🙂
