F.I.R.S.T Prensipleri İle Birim Test

Herkese Selamlar, bu yazımda birim test yazarken uygulanması gereken prensiplerden bahsedeceğim.

Birim Test Nedir ?

Birim Test, bir yazılımda test edilebilecek en küçük kod bloğuna farklı şartlar ve veriler ile testinin yapılıp davranışının gözlemlenmesi işlemidir.

Birim Test Yazmaya Neden İhtiyaç Duyulur ?

Avantajlar:

- Kod Kalitesini arttırır.

- Bir kalite kontrol süreci sağlar.

- Yazılım üzerinde sonradan yapılan değişikliklerin etkisini gözlemlemek kolaylaşır.

- Bu sayede geliştiricinin bug-fix döngüsünden kolayca çıkmasına olanak tanır.

- Geliştirilen yazılımdaki birimlerin hatasız çalışır olduğunu somut olarak görmek, yazılım üzerinde sonradan yapılan değişikliklerin etkisini gözlemlemek, hataları önceden tespit ederek testleri otomatize etmek, zamanı ve maliyeti azaltmak Birim Test’in en belirgin özellikleridir.

- Güvenilir bir geliştirme süreci sağlar.

- Proje üzerindeki birim test yazılmış bölümünde, yeni geliştirme yapacak ekip arkadaşları için birim testler bir izlence niteliği taşır.

Dezavantajlar:

- Bu kadar faydası olan birim test yazmanın dezavantaj olarak uzaktan bakıldığında geliştirme süresini uzattığı gözlemlenmektedir.

Fakat biraz daha detaylı incelendiğinde geliştirme süresini uzatmak yerine:

-Hata çözümü

-Projedeki en küçük birimlerin kendi kontrol mekanizmalari oluşturması

- Hata tespit süresi kısaltması birim test yazma ile genel anlamda yazılım maliyetini düşürmektedir.

Birim Testler Gereksiz Midir?

Yukarıdaki görselde de açıklandığı şekilde birim test olmadığında ya da gerekli önem verilmediğinde aslında kod güvenirliğinden ödün verilmiş olunur. Unit testin var olmaması aslında yukarıdaki döngünün oluşmasına yol açar.

Geliştiriciler, Regresyon koşulurken ya da entegrasyon yapıldıktan sonra koşulan testlerin tüm hataları tespit edileceğini ve birim testin zaman kaybı olduğu yanılgısına düşüyor. Geliştirilen yeni özellikler entegre edildikten sonra, test edilen regresyon paketinde çok kolay bulunabilen ve düzeltilebilen çok basit hataların izlenmesi ve düzeltilmesi çok uzun zaman alır. Bu sebeple küçük uniteler yani birimler ile mantıksal kod bloklarının test edilmesi, yapılan hataların kısa sürede çözülmesi, çok küçük bir değişiklik olarak gözüken bir geliştirmenin sebep olacağı hata durumlarının birim testler ile kontrol edilip bir kılavuz niteliği taşıması bu döngüden çıkılmasında yardımcı olur.

Birim Test Nasıl Yazılmalıdır?

- En küçük parçacığı test edilmeli

- Sadece bir senaryo test edilir.

- Kullanılan adımlar belirlenir.

- Test edilen kısım diğer kısımlardan bağımsız olmalıdır.

- Hızlı çalışabilmeli ve çabuk sonuçlar vermelidir.

- Okunaklı, anlaşılabilir ve sürdürebilir olmalıdır.

- Test başarısız olduğunda durmalı ve iyi bir hata raporu döndürmelidir.

İyi Uygulanmış birim test yazabilmenin ne denli önemli olduğundan ve nasıl olması gerektiğinden bahsedildi.

Fakat istenilen kaidelerin gerçekleştirilmesi amacıyla bir birim testin sahip olması gereken özellikler belirli bir çerçevede toplanması gerekir.

Birim test yazmanın da temel ilkeleri F.I.R.S.T. kısaltması kullanılarak bir araya getirilmiştir.

Birim test yazmanın da en iyi uygulama şekline gelecek olursak, her yazılan birim test kısaltma olarak F.I.R.S.T. prensiplerine uygun şekilde yazılması unit testin iyi şekilde uygulandığının delilidir.

F.I.R.S.T Prensipleri Nedir?

FIRST ilkeleri, Robert C. Martin tarafından “Clean Code: A Handbook of Agile Software Craftsmanship” adlı kitabında, bir geliştiricinin izleyebileceği bir dizi kural sunarak güvenilir testler yazmayı kolaylaştırmasına yardımcı olmak için önerilmiştir. İçeriği başlangıçta birim testlerin kalitesini artırmayı hedeflemektedir.

F.I.R.S.T. Prensipleri Nelerdir ?

Yazılım dünyasında çokça kullanılan kısaltmanın açılımı incelendiğinde:

• Fast

• Isolated

• Repetable

• Self-Validating

• Timely — Thorough

şeklindedir. Prensip denmesi sebebi ise yazılan birim testler, temel ilkeleri FIRST e uygun halde şekillendirildiğinde en iyi şekilde uygulanmış ve kullanılabilir olur.

Sırasıyla Unit Test temel ilkelerini ele alalım:

Fast

En küçük kod bloğuna yazılan test küçük olduğu kadar hızlı da olmalıdır.

Bu sebeple yazılan testlerin çalışması hızlı olması gerekir. Eger yavaş çalışıyorsa geliştirmenin birim test olup olmadığı yeniden gözden geçirilmelidir.

Geliştirme aşamasının başında bir kaç testimiz varken yada sonunda binlerce test varken bu testlerin çalıştırılmasından kaçınılmamalıdır.

Bu testler kısa sürede çalışmalı ve bunların sonuçlarını kısa sürede görülebilmelidir.

Yazılan testler kullanmak istenilmeyecek yavaşlıkta olmamalıdır.

Birim testlerde entegrasyon testlerindeki gibi birden fazla bileşen test edilmediği için çok kısa sürede çalışmalıdır.

Isolated

Birim test sınıfları hatta metodları izole olmalıdır.

Her test metodu sadece kendini gerçeklemelidir.

Önceki testlere bağımlı olmamalıdır.

Dışarıya bir bağlılığı bulunmamalıdır.

Diğer test senaryolarına ve testlerle ilişkisi olmamalıdır.

Yazılan testin izole olması ile herhangi bir zamanda, herhangi bir sırayla herhangi bir test çalıştırılması bu ilkenin başarılı şekilde uygulandığını gösterir.

Testler yazılırken Giwen-When-Then yapısı tercih edilmelidir.

Bu şekilde nelerin yanlış gittiğini, kodda bir hata olduğunda onun daha kolay bir şekilde bulunmasını sağlayacaktır.

Refactoring yapıldığında da testleri ayrı ayrı çalıştırmaya olanak sağlayacak maliyetleri düşürecektir.

Repeatable

Testler izole olması gerektiği gibi, herhangi bir zamana ve ortama da bağlı olmaması gerekir.

Test herhangi bir veriye bağımlı olmamalıdır.

Bunun icin mock yapısı ile sahte objeler kullanılmalıdır.

Bir birim testi farklı bir bilgisayarda çalıştırılırsa, aynı sonucu vermesi gerekir.

Bu ilke düzgün uygulandığı bir unit test her çalıştırıldığında aynı sonucu vermelidir.

Self-Validating

Bu temel ilkeye uyacak olan birim testler kendi kendine sonucunu açıklayan birim testler olmalıdır.

Yazılan testin başarılı ya da başarısız sonuçlanacağını test senaryosu sonucu bildirilmelidir.

Yazılan testin sonucu manuel olarak incelenmeden öğrenilecek şekilde olmalıdır.

Bunun yolu da Assert metodlarını kullanmaktan geçmektedir.

Timely — Thorough

Bu ilke ile beraber yazılan testin her çeşit kullanım senaryosunu ve daha fazlasını kapsayıcı şekilde olmalı ve bu şekilde test edilmelidir.

TDD(Test Driven Development) ye gore birim testler gerçek kod yazılmadan önce geliştirilmelidir. Bu sayede unit test refactorü kolaylaştırmak yerine refactorün kullanımını azaltır.

Daha temiz mimariler kurulmasına olanak sağlar.

Fakat bu ilkenin asıl anlatmak istedigi istenildiği zaman yazılan kod bloklarına uç durumlar sınırlayıcı test yazilabilmelidir.

Önerilen test yazımı ise TDD geliştirme sürecine uygun şekilde yazılmasıdır.

Kapsayıcı bakış açısıyla yazılan testler:

• Köşe kenar ve sınır değerleri ile test gerçekleştirilmelidir.

• Beklenmeyen değişken tipleri ile test edilmelidir.

• Farklı kullanıcılar ile farklı yetki ve erişim seviyelerine göre test senaryoları göz önünde bulundurulmalıdır.

Umarım herkes için açıklayıcı ve faydalı olmuştur. 😊