Birçoğumuz Agile Development, Test Driven Development (TDD) ve Extreme Programming gibi terimleri sıkça duyuyoruzdur. Altlı üstlü bu yöntemlerin tümünün uzlaştığı bir nokta ise yazılımımızın sağlığı için gerekli birim testlerin (Unit Test) yazılmasıdır.

Peki bu birim testleri nasıl yazmalıyız ki hem etkili olsunlar hem de bakımları kolay olsun? Aslında bu sorunun cevabının büyük bir kısmı sizin projenizin tasarımızla ilişkili. Çünkü birim testler adı üzerinde birimleri test etmelidir. Nesne yönelimli programlama (OOP) paradigması ışığında hazırlanmış bir yazılımın birimleri ise sınıflardır. Sınıflarımızı tasarlarken de hayatımızı kolaylaştırması için uymamız gereken belli başlı prensipler var. Mesela her sınıf değişime kapalı fakat genişletilebilirliğe karşı açık olmalıdır ki buna -Açık Kapalı Prensibi- denir. vs vs..

Duralımda bir soluklanalım derim ben bu noktada. Bütün bu prensipleri biliyoruz da kaçımız uyguluyoruz merak ediyorum. Teori ile pratik arasında dağlar kadar fark olabilir. MFÖ’nün dediği gibi “Teori de desen zehir gibi pratik dersen sallanmakta” da olabilir. Hatta “fazla teorik bilgi yaratıcılığı öldürür” de diyebiliriz.

Ben size benim nasıl yazılım geliştirdiğimi anlatayım. Efendim, her şeyden önce yukarıda bahsi geçen metodolojiler, prensipler vs hakkında az çok bilgimizin olması güzeldir, işe yarar. Fakat bunları uygulayacağım diye asıl yapmamız gereken işten uzaklaşmakta pek akıl karı değil. Bundan dolayı ben gidipte bir projeye testleri yazarak başlamam. Önceden tasarım yapıp ta başlamam. Kafamda üstün körü bir tasarım yaparım fakat benim için asıl önemli olan, test edilecek, tasarımı yansıtacak kod olmasıdır. Kod yazarak başlarım ve yazdığım kodun doğru çalışıp çalışmadığını kontrol etmek için test yazarım. Kodu değiştirdikçe testleri de değiştiririm.

Peki diyeceksiniz ki, öyle paldır küldür kod yazamaya başlarsak tasarımımız ne kadar iyi olabilir? Bence her yeni bug çıktığında veya her yeni özellik eklemek istediğinizde sınıflarınızı ve dolayısıyla ilk tasarımınızı değiştirmek zorunda kalırsınız. Bunu hızlı bir şekilde yapabilmek için iyi bir IDE ve iyi bir Refactoring aracı kullanmanız şart. Ben Visual Studio’yu Resharper olmadan kullanamıyorum. Kodu parçalama bölme değiştirme işlemlerini Resharper ile saniyeler içinde hallediyorum. Bunun verdiği rahatlıkla sınıfları aklıma ilk gelen şekilde yazıyorum. Yazdığım metod bu sınıfa mı ait olmalıymış, adı ne olmalıymış, buraya bir interface tanımlasam daha mı iyi olurmuş diye hiç derdim tasam yok. Kodu yazarım. Oraya interface lazımsa zaten bir sonraki özelliği eklemem gerektiğinde bunun gereğini göreceğim ve Resharper’a Extract Interface diyeceğim. Metoda oraya ait değilse, Move diyeceğim, adını değiştirmem gerekiyorsa rename diyeceğim. İşime devam edeceğim. Herkes bir yöntem ortaya atıyor ya, alın size Bug Driven Development! Her bug çıktığında onun için bir test yazarım sonra bug’ı düzeltirim. Her hatada tasarım daya iyiye gider diyorum o zaman alın size Nature Driven Development! Uzun sözün kısası; bu prensipleri bilelim ama onlarla kafamızı da bulandırmayalım. Bütün bu prensipleri uygulayacağız diye ortaya bir şey çıkartamıyorsak bir sorunumuz var demektir. Efendim, bazılarınız böyle kod yazmak buglara davetiye çıkarır diyebilir. Tasarım iyi olmazsa ileride daha ciddi problemlerle boğuşulur diyebilir. Ben bu güne kadar, ilk tasarımı ile yıllarca hiç değişmemiş bir kütüphaneye rastlamadım. Her yazılımın illaki hatası olacaktır ve hiç bir tasarım mükemmel çıkmayacaktır. Ne tasarlıyorsanız bugün için tasarlayın. Yeterki ortaya bir şey çıksın. Bu yazıda olmadı ama ilerki yazılarda yine birim testler, kullanabileceğimiz kütüphanelerden bahsedeceğim ama bunları hangi sıra ve ne sıklıkla kullanacağınız size kalmış. Mutlu yıllar!