27 Nisan 2014 Pazar

Unit Test Yaparken Mock Object'lerden Yararlanma

Merhabalar arkadaşlar;
  Geçen hafta birlikte code coverage yapmanın faydaları, çalışma yöntemi, nerelerde kullanıldığına dair alıştırmalar yapmıştık. Bu hafta ise unit test yaparken mock objelerin kullanımından bahsedeceğim. Karmaşık objeleri basitleştirilmiş fonksiyonlarıyla taklit eden objeye Mock objesi denir. Bir birim testi donanım, bağlantı veya başka herhangi bir kaynağı benzetimi açısından Mock objelere ihtiyaç duymaktadır. Çünkü bahsi geçen bu dış kaynak fonksiyonları birim testi kümesinde yer almamaktadırlar. Birim testi aynı zamanda performans için de Mock objelere ihtiyaç duymaktadır. Çünkü canlı sistemde çalışan bir obje çok yüklü olabilir ve bu nesnenin sadece belirli kısımlarına ihtiyaç duyulabilir. Unutulmamalıdır ki test performansı çok önemlidir. Aksi takdirde test çalıştırılması külfete dönüşebilir.

Aşağıdaki sebepler mock nesneleri gerçek nesnelere tercih etmemize neden olur;

  • Gerçek nesneler beklenmedik sonuçlar üretir.
  • Gerçek nesnelerin oluşumu ve kullanımı zordur.
  • Gerçek nesneler yavaştır.
  • Gerçek nesneler kullanıcı arayüzüne sahiptir, bu durum yavaş çalışmalarına ve sistemi yormalarına sebep olur.
   Şimdi sizlere interface ile yapılmış bir örnek göstereceğim ardından bu örneğimizi mock objesi ile yeniden düzenleyeceğiz.





















  Görüldüğü üzere IWarehouse adında bir interface oluşturduk. Büyük projeler üzerinde çalışırken bu interfacelerden çokça üretilir ve sistem üzerinde test yaparken zaman kaybına ve birikmelere sebep olur. İşte burada mock objeleri bizim yardımımıza yetişmektedir.
Şimdide yazdığımız kodu mock objesi ile yeniden derleyelim.













Testimizi yazarken takip etmemiz gereken işlem basamakları şu şekilde olmalıdır;
  1. Oluşturulma anında içinde ürün ve miktar geçen, Order object oluşturun.
  2. Sonrasında Warehouse adında mock object oluşturulur.
  3. Mock object ile yapılmak istenen, beklenen durumlar nedir onu belirtiriz. Şöyle ki bu örneğimizde 'HasInventory' metodunun 'true' değer döndürmesi, 'widget' ve '50' parametrelerinin object'e paslanması beklenir.
  4. Remove metodunun çağırıldığı zaman, null değer döndürmesi (void metod olduğundan) ve 'widget' ile '50' parametrelerinin okunması beklenir.
  5. Order nesnemizin MockInstance sayesinde yalancı bir nesne oluşturarak içinin doldurulması gerektiği belirlenir.
  6. Order nesnesinin MockInstance ile doldurulmasının yeterli olup olmadığı doğrulanır.
  7. Doğrulama işlemi Warehouse adındaki Mock Object içinde yapılır. (Bu doğrulama ancak beklenen bütün metod ve parametreler düzgün çağırıldığı zaman mümkün olur.)

  Görüldüğü üzere Mock object'ler gerçek object'lerin birer Proxy object'leridir. Yani gerçek nesne gibi davranır ama bunun için yazılımcıyı hiçbir class vs yazmak zorunda bırakmaz. Bir birimin mock objectini elde etmek için virtual olması (bir interfaceden türemiş olması veya bizzat virtual anahtarıyla işaretlenmiş olması) gerekir. 

  Bu haftalık anlatacaklarım bu kadar arkadaşlar. Mock Objeler yaparken en çok dikkatinizi çekmek istediğim muhakkak belli bir interface'den türemiş olmaları gerektiğidir. Birim testleri yazıyoruz fakat ne kadar açık ve kodun iyi derlenmiş olup olmadığının kontrolü gereklidir. Haftaya bu konu üzerinde çalışma yapacağız. Kaliteli birim testlerin hangi özellikte olması gerektiğinden bahsedeceğim. Sizde artık örnekler yapmaya başlayabilirsiniz. Takıldığınız yerler olursa bana mail atabilir ya da yorum bırakabilirsiniz. Haftaya görüşmek üzere hoşçakalın..

20 Nisan 2014 Pazar

Unit Test Oluştururken Code Coverage Yapma


 Merhabalar arkadaşlar;
  Geçen haftayı hatırlayacak olursak NUnit Gui Tool kullarak hatalarımızı tespit etmiştik. Bu hafta sizlere Unit Testlerimizi oluştururken Code Coverage yapmanın öneminden bahsedeceğim. Code Coverage, yaztığımız testlerin kontrol ettiği kodun, yazdığımız koda oranı demek. Ben genelde % olarak baz alındığını gördüm. Code coverage’ımız ne kadar yüksekse unit testlerimizden faydalanma oranımız da o derece yüksektir. Başka bir deyişle bir kodumuzda bir hata olduğunda, hata cover etmediğimiz bir kod bölümüne denk gelmişse biz bunu unit testler ile bulamayacağız demektir.  Daha başka bir deyişle “Code Coverage” hataları tespit etmede kullanılan önemli bir kavramdır.


Visual Studio Code Coverage Özelliğini Açmak

  Visual Studio 2012 üzerinde geliştirdiğimiz Test Driven uygulamaların ne kadarının test kapsamında olduğunu anlamak için code coverage aracından faydalanırız. Tabi bu özellik Visual Studio default test aracıyla çalışırken geçerli. Piyasadaki diğer test araçlarını kullanıyorsanız onlara göre ayar yapmalısınız. Visual Studio üzerine dotCover Tool'u kurulması gerekir.

 dotCover yazılımcıların UnitTestleri ne ölçüde bildiklerinden emin kılmak için üretilmiş bir tooldur. Şu anda 4 Visual Studio sürümü dotCover ile entegre olmuş durumdadır. Visual Studio 2005,2008,2010,2012 ve 2013 sürümleridir.


Unit Testlerin Çalıştırılması ve Yönetimi

dotCover bir başka UnitTest geliştirme aracı olan ReSharper ile birlikte çalışmaktadır.


















  Runner, Visual Studio çalışan oturumları aracılığıyla yönetme Unit Testleri verir ve birden çok birim test çerçeveleri destekler: MSTest, NUnit, xUnit ve MSpec.


Visual Studio üzerinde Coverage Basamakları

  Coverage Datayı görselleştirmek için dotCover editörü sayesinde covered ya da uncovered kod satırlarını birbirinden ayırabiliriz.


















dotCover bunu kendi belirlediği özel renklendirme yöntemiyle yapmaktadır.


Filtreleme ve Harici Düğümleme Olayı

  Bazen kodlama yaparken covered data solution penceresini görmek istemeyebilirsiniz. Özel bir proje geliştirirken belirli metodlarını yada sabit değişkenleri test olayına dahil etmek istemeyebilrsiniz. Aşağıda vereceğim örnekte Obsolete Attribute olaya dahil edilmek istenmemiştir. Filtreler belirli özelliklere sahip işaretlenmiş (ya da işaretli değil) coverage filtelerinin kod toplama özelliğinden faydalanılarak yapılandırılır.


















   Bu duruma alternatif olarak, kapsama verilerini seçtiğiniz halde harici düğümleme ile kapsama ağacından belirli düğümleri seçebilirsiniz. dotCover bu durumda kapsama istatistiklerini yeniden hesaplar.

   Code Coverage özelliği daha çok büyük projelerde kullanıldığı için sizlere internetten indirdiğim servis uygulaması ile göstermeye çalışacağım. Bu sayede hem görsel olarak daha rahat kavrayıp, yapmamız gerekenleri belirlemede işlevsel basamakları kullanacağız.























Visual Studio Entegrasyonu

dotCover Visual Studio üzerine entegre edilerek code editore gerek kalmadan sonucçları analiz etmenize ve görselleştirmenize yarar.











  
   Code Coverage yaparken if-else blokları sayesinde testin durması ya da devam etmesi için şartlar koyabilirz. Şöyleki projenin belirli kısımlarında seçilen kod satırının %100'ü coverage yapıldığı zaman testin durmasını isteyebiliriz.




















  Bu haftalık anlatacaklarım bu kadar arkadaşlar, haftaya Unit Test yaparken Mock Object'lerin kullanımını göreceğiz. Yazımı burada sonlandırıyorum haftaya görüşmek üzere hoşçakalın..

Referanslar

1)http://www.ncover.com/support/docs/v3/how-to/running-ncover-with-your-unit-testing-framework/nunit
2)http://codefez.com/nunit-and-code-coverage-with-ncover/

11 Nisan 2014 Cuma

Test Tarafında Oluşabilecek Hataları Tespit Etme


Merhaba arkadaşlar;
  Geçen hafta NUnit Gui Tool kullanarak birim testlerin nasıl oluşturulup test edildiğine dair uygulamalar yapmıştık. Bu hafta ise kaldığımız yerden devam ederek test yaparken oluşabilecek hataları tespit edip, daha düzenli kod yazmak için kullanılan çeşitli metodlardan bahsedeceğim. Bu sayede daha hızlı nasıl test yapıp, uygulamalarımızı pratik hale getirebilmeyi öğreneceğiz.

Hataları Test Etmek

  Hata yönetimi bütün yazılımlarda önemlidir. Test tarafında da bir hatanın oluşup oluşmadığını test edebiliriz. Bunun için ExpectedException attribute’sini kullanıyoruz.
 
  Paydaya sıfır yazılması durumunda bir hata oluşumunu test etmek gerekir. Şimdi bir metod daha yazalım ve bu hatayı handle edip etmediğimizi test edelim.














  Dikkat ederseniz burada Assert yoktur. Bunun yerine aşağıdaki gibi bir attribute ekledik.




  Build edip TestClient’a geçtiğimizde yeni metodun eklendiğini fakat başarısız olduğunu görüyoruz.
































  Demek ki bu hatayı kontrol altına almamışız. Hemen aşağıdaki gibi bir değişiklik yapalım.
Artık testimiz başarılı olacaktır.

SetUp ve TearDown Attribute’leri

   Bu attribute’ler genellikle refactoring dediğimiz süreçte kullanılırlar. Mesela dikkat ederseniz Matematik sınıfının referansını ben iki metodda da kullandım. Dolayısıyla ben aynı kodu iki kere yazdım. Bunu yapmak yerine Setup attributesine sahip bir metod ile, her testin öncesinde çalışacak bir yardımcı metod kullanılabilir. Kısacası, adı üstünde, bir SetUp işlemi yapılıyor.

Aşağıdaki gibi değişiklik yaptım.































  Çok daha temiz bir kod yazmış olduk. Burada dikkat etmenizi istediğim husus şudur ki, SetUp ile süslü metod, her test metodunun öncesinde çalıştırılır.


 TearDown attribute’si ise her hest metodunun sonunda çalışmasını istediğiniz kodlar var ise, kullanılabilir.


  Bunun yerine setup metodunun tüm sınıflardaki tüm testlerin başında çalışmasını isterseniz veya teardown metodunun tüm sınıflardaki tüm testlerin sadece sonunda çalışmasını isterseniz aşağıdaki gibi bir sınıf oluşturup bu kodu kullanmaya ihtiyacınız var.
































Ignore Attribute

  Bu metodu özellikle yazılan testlerden emin olmadığınız durumlar oluştuğunda, sırf bu testi gözardı ettiğinizi işaretlemek için kullanabilirsiniz. Tek yapmanız gereken bu test metodunu [Ignore] ile süslemek.









































Category Attribute

  En güzel test tecrübelerinden biri de test operasyonlarınızı kategorilere bölmek olacaktır. Bir kategori oluşturmak için [Category] attribute’tan yararlanıyoruz.

Ben yazdığım iki test metodunu iki kategoriye ayırdım.



  Build edip, Test Runner Client’a geçtiğinizde Categories sekmesine iki kategorinin düştüğünü aşağıda görebilirsiniz. Buradan istediğiniz kategori veya kategorileri seçerek testlerinizi daha hızlı sonuçlandırabilirsiniz.































  Bu haftalık anlatacaklarım bu kadar. Haftaya Unit Test yaparken Code Coverage, yani kodun ne kadarının test edildiği konusundan bahsedeceğim. Şimdilik yazımı sonlandırıyorum haftaya tekrar görüşmek üzere hoşçakalın..


Referanslar