Unit Test Üzerine

Son birkaç yıldır gelişen yazılım mimarileri ile yazılım geliştirme süreçleri de değişiyor ve yeni teknikler, yöntemler oluşuyor. Eğer yazılımcı kapsamlı bir projede yer almıyorsa bu tarz yeni değişiklikleri, yaklaşımları da kullanma yeteneğini kazanamıyor.

Bireysel olarak yazılımcı, bu yenilikleri kullansa da, kapsamlı bir şekilde bilgisini tartabilecek, karışlaştırabilecek, ölçecek bir duruma ancak iş görüşmelerinde ya da emin olunmayan forumlarda karşılaşıyor.

Geçtiğimiz haftalarda yeni bir projeye başladık. .Net core ile yazmaya başladığımız projenin tüm modüllerinin nasıl ve ne kadar doğru çalıştığını ölçmek için de birim testlerini (unit test) de yazıyoruz.

Öyle ki, yazılımcı eğer kuralına göre birim testlerini uygularsa, bu yöntem yazılımcıyı belli bir geliştirme standardına girmesini zorluyor.

Neler oluyor ?

Mesela single responsibility denen kavramı, bağımlılılıkların (dependecy) doğru olup olmadığını, interface segregation gibi ayrımları yapmaya ve kontrol etmeye zorluyor.

Çünkü birim testlerini kapsamı aslında yazılan iş mantığının düzgün işlenip işlenmediğini ölçebilmek. Dolayısı ile yazılan metodun içeriği eğer düzgün değilse ve test edilemiyorsa, bir yerlerde birşeyler yanlış bağlanmış, patternlere uyulmamış denebilir.

Test edilemeyen metodlar çoğunlukla spagetti kod’a dönmüş, yapması gereken işten fazlasını yapan, satırlar dolusu kodlardan oluşuyor. Dolayısı ile bir bakıma birim testleri, mevcut legacy kodu refactor etmeye de zorluyor.

Öte yandan geliştirme süresi nispeten uzuyor. Mesela hızlıca tek bir satırda çıkabileceğiniz kodu, testleri ve validasyonları ile beraber yazma zorunluluğu doğuyor. Dolayısı ile yazılımcı sağlam adım atarken öte yandan geliştirme zamanı biraz daha uzuyor.

Nereden Başlamalı ?

Tabi ki istenilen yerden başlanabilir. Birim testlerinin oluşturulabilmesi için önce test edilmek istenen metodun yeniden düzenlenmesi (refactor) edilmesi gerekiyorsa yeniden düzenlenmesi, patternlerin ve bağımlılıkların geçerliliğinin doğrulanması gerekir.

Birim tesleri için yardımcı olabilecek birkaç kütüphaneden de söz edebiliriz.

Mock – Mock kütüphanesi, testi yapılacak olan sınıfın bağımlılıklarını bir anlamda taklit etmek için gereken altyapıyı sağlıyor.

Xunit – Xunit hali hazır da bulunan MSTest kütüphanesinin bir alternatifi olarak karşımıza çıkıyor.

MSTest – Herhangi bir test projesi açtığınızda varsayılan olarak bu kütüphane de kullanılabilir.

Visual Studio’nun Enterprise sürümünlerinde de Live Unit testing özelliği, yazma anında tüm testlerin geçerli olup olmadını, kod kapsamının yüzdelerini gösteriyor. Böylelikle henüz yazma anında bile, yazılımcı ne yaptığı konusunda real-time geri bildirim alıyor.

Sonuç

Benim şahsen gözlemlediğim değişim; birim testleri eğer doğru bir şekilde yazılmaya başlanırsa, yazılımcıyı doğru şeyleri yapmaya zorluyor ve kod kalitesi de artıyor. Geliştirilen kod sadece yapmak zorunda olduğu şeyi yapıyor (Single Responsibilty) ve yapılan işin geçerliliği henüz canlı ortama geçmeden görülüyor.

Eğer CI/CD süreçleri işletiliyorsa, canlı ortama bozuk kodun atılması da önlenmiş oluyor.

Yardımcı linkler