S.A. Arkadaşlar,
Bugün yine unit(birim) test ile ilgili bir yazı ile karşınızdayım. Unit testlerden öyle hemen vazgeçmek ya da önemsememek mümkün değil. Zira birim testler çok daha kararlı kod geliştirmemize olanak sağlar hatta bizi SOLID yapılara zorlayan bir yanı da vardır...
Daha önce birim testlerle ilgili bir yazı kaleme almıştık, fakat o yazıda daha çok veri kümelerini incelemiştik, bu defa ise void olan metodların nasıl test edileceği üzerinde duracağız. Bunun için bazı yöntemler olsa da malesef void metodları test etmek için sınırlı seçeneklerimiz bulunuyor. Bu yüzden mümkün mertebe kodunuzu düzgün dizayn etmeniz ve test edilebilir metodlar yazmak giderek önem kazanıyor.
Yukarıda da belirttiğimiz gibi, bir metodun sağlıklı olarak test edilebilmesi için bir sonuç döndürmesi gerekmektedir. Çünkü metod sonucunda bir değer döner. Gelen bu değeri, beklediğimiz değer ile karşılaştırırız ve bunlara göre bazı sonuçlar, hatalar veya mesajlar döndürürüz.
Void olan metodlar ise her hangi bir dönüş sağlamadığından bunları test etmek için farklı yollar aranmaktadır. Biz de bu yollardan bazılarını kendimizce inceleyeceğiz.
Void bir metodunuz varsa bunun büyük ihtimal iki sebebi vardır. Ya metoddan bağımsız bir şeyler yapmasını bekliyorsunuzdur ya da bilgilendirme amaçlı bir şeyler yapıyorsunuzdur. 1.Tip metod giren parametre değeri üzerinden test edilebilir, fakat 2.tip metodun genelde birim testi yazılmaz. Buna rağmen bunu test etmek için bazı yöntemler bulunmaktadır. Aşağıdaki örnekte de görüleceği üzere list üzerinde yapılan değişikler sonucu tekrardan list nesnesinin değeri kontrol edilebilir. Sizin örneğinizde bunlar farklılar gösterebilir.
public void DoSomething(List<string> list)
{
//...
list.Add("Algomedi");
//...
}[Fact]
public void TestSomething()
{
var list = new List<string>()
{
"Malik",
"Masis"
};
DoSomething(list);
Assert.Equal(3, list.Count);
} Metodun içeriğine bağlı olarak bazı kontroller yapılabilir. Eğer metod içerisinde her hangi bir hata yakalama kodu mevcutsa ve bu metod çalıştığında bir hata fırlatmasına bağlı olarak onu test edebiliriz. Metod hata fırlatıyorsa ve siz bunu yakalıyorsunuz hata vardır, aksi halde kod düzgün çalışmaktadır. Şöyle ki;
[Fact]
public void TestSomething()
{
try
{
YourMethodCall();
Assert.True(true);
}
catch {
Assert.True(false);
}
}Assert.Throws<ExpectedException>(() => YourMethodCall()); // bu şekilde de kullanılabilir. Void olan metod bool olarak dönüş tipi sağlayan bir metoda da dönüştürülebilir. Her hangi bir sonucu döndürmesine gerek olmasa da en azından buradan sıkıntısız bir sonuç döndüğünü belirtebiliriz. Bu şekilde test edilebilir bir metod yazmış oluruz. Örneğin veri tabanına bir kaydetme işlemi yapıyorsunuz (mocklama kullanmaz iseniz integration test yazmaya başlamış olabilirsiniz, dikkat lütfen) bunu void olarak kaydetmek yerine, işlem eğer başarılı olduysa bool olan bir değer döndürülebilir.
public void Save() //bu kullanım yerine
public bool IsSave() //bu kullanım tercih edilebilir Void metodlarda bazen dosyaya yazma tarzı işlemler yapabiliyoruz. Bu metodlar void dahi olsa kaydettiğimiz dosyayı varlığını doğrulatıp test edebiliriz. Eğer dosya doğru bir şekilde oluştuysa bunda işlemin başarılı bir şekilde çalıştığını kabul edebiliriz. Aşağıdaki örnekte gördüğümüz gibi metodun her hangi bir yerinde dosyaya kaydetme işlemi bulunmaktadır.
File.WriteAllText(path, contents); //yazdığımız metod içinde bir satır[Fact]
public void TestSomething()
{
Assert.True(File.Exists(path)); //dosya belirtilen yerde var mı?
} Bunların dışında atladığımız veya aklınıza gelen bir yöntem varsa yorumlara yazabilirsiniz. Tüm bunları anlattığımız halde yazının başında da belirttiğimiz gibi mümkün olduğu sürece test edilebilir kod yazmaya özen göstermek gerekir. Eğer test edilemeyen bir metod yazmışsanız tekrardan kodunuzu gözden geçirmeniz ve gerekirse onu refactor etmeniz güzel bir seçenek olarak her daim aklınızda bulunmalıdır.
Tek bir iş yapan, test edilebilir metodlar yazmak dileğiyle.
Hiç yorum yok:
Yorum Gönder