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!

Kod Kapsama nedir?

Kod kapsama ile ne gibi bir ölçüm yaparız?

• Test senaryolarımız tarafından ulaşılmayan, test edilmeyen kod parçacıklarını tespit edebiliriz
• Test edilmeyen kod parçalarını da içerecek yeni testler yazabilir ya da eski testlerimizi genişletebiliriz.
• Gereksiz testleri tespit edip kaldırabiliriz.
• Aslında hiç kullanmadığımız kod parçacıklarını ayıklayabiliriz

Diyelimki bir tane Registration adında bir DTO sınıfınız ve bu sınıftaki bilgileri doğrulayan RegistrationValidator diye başka bir sınıfız var.

public class Registration
{
  string name;
  string password;
  public string Name
  {
    get { return name; }
    set { name = value; }
  }
  public string Password
  {
    get { return password; }
    set { password = value; }
  }
}
public class Validator
{
  public const int MINPASSWORDLENGTH = 6;
  public const int MINNAMELENGTH = 5;
  protected virtual bool IsValidUserName(Registration registration)
  {
    return registration.Name.Length > MINNAMELENGTH;
  }
  protected virtual bool IsValidPassword(Registration registration)
  {
    return
      registration.Password.Length > MINPASSWORDLENGTH &&
      registration.Password.IndexOfAny("0123456789".ToCharArray())>-1;
  }
  public virtual bool IsValid(Registration registration)
  {
    return IsValidUserName(registration) && IsValidPassword(registration);
  }
}

[TestFixture]
public class ValidationTests
{
  private Validator validator = new Validator();
  private Registration _registration;
  [SetUp]
  public void SetUp()
  {
    _registration = new Registration();
    _registration.Name = "t-hex";
    _registration.Password = "abcd";
  }
  [Test]
  public void Shouldnotvalidateifnameisshorterthanminumunlength()
  {
    Assert.IsFalse(validator.IsValid(registration));
  }
  [Test]
  public void Shouldnotvalidateifpassworddoesntcontainnumbers()
  {
    Assert.IsFalse(validator.IsValid(registration));
  }
  [Test]
  public void Shouldnotvalidateif_password__is_shorter_than_minimum_length()
  {
    Assert.IsFalse(_validator.IsValid(_registration));
  }
}

Peki gerçekten doğru mu yaptık? Bir de NCover ile bakalım:
Neden oranlar bu kadar düşük? 100% olması lazım zaten iki üç tane metodu test ediyoruz burada. Hatta sonuçlardan anladımıza göre get_Password, IsPasswordValid metodları hiç çağırılmamış!

Bunun nedeni lazy evaluation. C# derleyicisi tümü “ve” ile bağlanmış bir ifade de ilk false döndükten sonrakileri hiç çalıştırmaz çünkü zaten her durumda tüm sonuç false olacaktır. Bu durumda da biz ilk testi yaptığımızda uzunluk 5 karakterden kısa olduğu için false alıyoruz ve aslında şifreyi hiç kontrol etmiyoruz. Hatta daha vahimi ise şifreyi test eden kodumuzu gerçektende yanlış yazmışız, IndexOfAny metodu -1′ eşit değil -1′den büyük olmalıydı.

Kodumuzu düzeltelim:

protected virtual bool IsValidPassword(Registration registration)
{
  bool valid = registration.Password.Length > MINPASSWORDLENGTH;
  valid = valid && registration.Password.IndexOfAny("0123456789".ToCharArray()) > -1;
  return valid;
}
//testlerde de
[Test]
public void Shouldnotvalidateifpassworddoesntcontainnumbers()
{
  _registration.Name = "longername";
  _registration.Password = "abcdefg";
  Assert.IsFalse(validator.IsValid(_registration));
}

Burdan 2 sonuç çıkarabiliriz: Birincisi; Test edilmesi gereken koşulların hepsini “ve” ile bağlamayın, bu hem okunurluğu azaltır, hem de yukarıdaki gibi hatalara neden olabilir. Onun yerine önce boolean değişkenlere değerleri atayın sonra kontrol edin. İkincisi de hiçbir zaman emin olmayın.