FakeItEasy ile Mocking işlemleri

14 Kas

FakeItEasy açık kaynak kodlu bir .Net mocking Framework’dür Bu framework sayesinde istediğimiz tipe ait dinamik fake nesneler oluşturabiliriz. Kolay anlaşılır ve uygulanabilir bir altyapıya sahiptir. Kullanımı ise basit bir şekilde şöyledir:


IMemberService service = A.Fake<IMemberService>();

A.CallTo(()=>service.IsValid("validUser")).Returns(true);
A.CallTo(()=>service.IsValid("invalidUser")).Returns(false);

MemberController controller = new MemberController(service);
bool isValid = controller.ValidateUser("validUser");

Yukarıda IMemberService türünden türetilmiş somut bir fake sınıf yazmamıza gerek kalmadı. Çünkü bu işlemi bizim yerimize FakeItEasy gerçekleştirdi. A.Fake<IMemberService>() şeklinde yeni bir somut nesne oluşturdu. Yine service nesnesinin metotlarına ait davranışları da biz veriyoruz. IsValid() metoduna hangi parametre ile çağrıldığında nasıl davranacağını A.CallTo() metodu ile bildiriyoruz. Artık MemberController sınıfı dışarıdan almaya ihtiyaç duyduğu IMemberService hazır.

FakeItEasy aracı Test Driven Development geliştirme için çok kullanışlı bir üründür. Eğer önceden aşina olduğunuz bir mocking framework yoksa kullanmaya değecek bir üründür.

TDD Sizi Yavaşlatmaz

19 Ağu

TDD(Test Driven Development) yaklaşımı için ortaya atılan eleştirilerden biri kod geliştirmeyi yavaşlattığı yönündedir.  TDD yaklaşımı, yöntem olarak şelale(waterfal) tarzı yaklaşımdan çok farklıdır. Dolayısıyla şelale tarzı geliştirmeyi bırakmak demek eski alışkanlıklardan vazgeçmek demektir. Ben TDD yaklaşımını ilk uygulamaya başladığımda, kendimi sanki sağ ayakla futbol oynarken sol ayakla oynamaya alıştıran oyuncu gibi hissetim. Çünkü alışkanlığımın tersi bir durum söz konusuydu. Önce kodu yazıp sonra test etmeye alışmışken, önce testin yazılıp sonra kodun üretildiği bir ortamda buldum kendimi.

Eski yöntemde yazdığım kodu test etmek için kullanıcı arayüzü (form, console) hazırlamam gerekirdi. Bu da hayli bir zaman kaybı demekti. Test edilecek sınıfa ait üyeleri test etmek için kullanıcı arayüz hazırlamak zahmetli ve uzun süren bir işlemdir. Test arayüzünü hazırladıktan sonra, ilgili forma kritik test parametrelerini elle tekrar tekrar girip denemek gerekir. Örneğin matematiksel bir fonksiyonu hesaplayan bir metodu test etmek için önce parametrenin sıfırdan küçük, sonra sıfır, sonra sıfırdan büyük olması durumunu sürekli test etmek gerekebilir. Metodun özellikleri arttıkça test sayısı da artar. Arada bir hata alırız ve hatayı düzelttikten sonra testleri tekrar yapmamız gerekir. Test senaryoları arttıkça, elle yapılan işlem sayısı da doğru orantılı olarak artar.

Testlerin elle yapılmasının gereksiz yere zaman harcadığını fark eden yazılımcılar, test sürecinin otomatik işletilmesi gerektiğine karar vermiştir. Tek bir tuşa basarak yazılımın bütün testlerini çalıştırıp kısa bir süre içinde geliştiriciye sonucu veren araçlar geliştirilmiştir. Bu araçlar sayesinde testler hızlı bir şekilde yapılmaktadır.

TDD yaklaşımı testlerin otomatik bir şekilde çalıştırılması anlamına gelmez. Çalışan koddan önce testin yazılması anlamına gelir. Test öncelikli(Test First) yaklaşım olarak da adlandırılır. TDD yaklaşımında kodu yazan kişi, kodunu kullanıcı gözü ile görerek geliştirmeye çalışır. Bu yazdığım API veya Framework’ün kullanıcısı olsam nasıl bir sınıf ve metod yazardım diye düşündürür geliştiriciyi. Bu geliştiriciyi yavaşlatmaz. Kodlama yapan kişinin koduna olan güvenini arttırır. Kişi geliştirdiği koda hükmetmeyi öğrenir. Testler başarıyla gerçekleştiğinde kişi güvenilir bir kod ürettiğini bilir.

TDD yaklaşımında uzmanlar hızdan ziyade kaliteli ürün geliştirmenin önemli olduğuna vurgu yapmaktadır. Yani müşteri sizin hangi yöntemlerle geliştirme yaptığınıza değil ortada düzgün çalışan bir uygulamanızın olup olmadığına bakar. Puanınızı buna göre alırsınız. Kötü uygulamalar demek hata oranı yüksek, kullanımı zor ve zaman kaybettiren uygulamalar demektir. Kötü uygulamaların üzerine yeni özelliklerin eklenmesi veya mevcut özelliklerinin değiştirilmesi zordur. Test edilmeden hızlı bir şekilde geliştirip teslim edilen uygulamaların bakımı ve ilerletilmesi sonraki aşamalarda zaman kaybettirici olacaktır. Değişimin zamanında yapılamaması da müşteri memnuniyetini önemli ölçüde azaltacaktır. Hiçbir müşteri binlerce satır boş koda para harcamak istemez. Binlerce satır kod yazmış olmak kişiyi iyi bir geliştirici yapmaz. (Ancak bazı kariyer ilanlarında aranan programcı kriterleri arasında “10000 bin satır kod yazmış olmak” şeklinde komik maddelere rastlarız)

TDD ile geliştirme yaparken çalıştırdığınız testlerin sonucunu almak çok uzun sürüyorsa bu durum, kodunuzu direkt olarak bir veritabanına veya bir dosya sistemine veya bir ağa bağımlı olmasından kaynaklanıyordur. Testlerin hızlı çalışması açısından kodların bu tür ortamlardan izole edilmesine dikkat edilmelidir. Test ortamında bu şekilde hız kazanmak mümkündür. Gerçek veritabanı ile dakikalarca sürecek testleri izole edilmiş ortamlarda saniyeler içinde gerçekleştirmek mümkündür.

TDD yaklaşımı genel olarak uygulamanın geliştirme sırasında ve ömrü boyunca devamlılığının sağlanabilmesi açısından size hız katar. Bir  çok firmanın sonraki versiyonlarını çıkaramadığı için çöpe giden uygulamaları vardır. Bir kurumda çalışan bir tanıdığımın anısıyla sözümü bitirmek istiyorum. Kurumuna yazılım yapan firmadan, mevcut yazılıma yeni bir özellik eklemesini istemiş. Firmanın verdiği cevap ise şu olmuş:  “Sen şimdi bir binanın aradaki bir katını kır ve araya bir kat ekle diyorsun, bu çok zor”.

Renk Tabanlı Unit Test Süreci ve Örnek Uygulama

25 Oca

Renklerle ilgili işlemler yapmak, component’lerin renk tabanlı özelliklerini değiştirmek, yazılım geliştirme sürecinde uyguladığımız basit operasyonlardır. Bu kez reklerle ilgili işlemlerin unit test mantığı kullanılarak nasıl gerçekleştirilebileceği incelemeye çalışacağız. Aslında yapacağımız işlem basit olarak bir ana renge ait değişik renk tonlarının oluşturulması şeklinde ilerleyecek. Örneğin “kırmızı” renge ait “N” adet renk tonunu unit test ile oluşturmaya çalışacağız. Daha sonra oluşturulan bu renk tonlarını bir WPF uygulaması içerisinde uygulayacağız. Senaryomuzu basitçe sunduktan sonra işleyişe geçebiliriz. Ortaya çıkan ürün aşağıdaki gibi olacaktır.

colorUnitTest2

Sürecimiz önce testlerin yazılıp daha sonra geçen testlerden kod üretimi şeklinde gelişmektedir. Bunun için öncelikle Visual Studio üzerinde “ColorManager” isimli bir proje başlatarak ilerleyelim.

colorUnitTest1

Devamında “ColorManager.Tests” adında bir proje daha ekleyerek test sürecinin işletileceği bir proje başlatıyoruz.

Bu uygulama için kullanılan Unit Test aracı, Nunit test aracıdır. Nuget Package Manager üzerinden eklenebilen bir referanstır.

İlk testlerimizi aşağıdaki geibi geliştirmeye başlayabiliriz.

[Test]
public void Create_WithClassSize1_ReturnsOneColorInList()
{
      var inputColor = Colors.Red;
      var inputSize = 1;

      ColorToneCreator creator = new ColorToneCreator();

      var result = creator.Create(inputColor, inputSize);

      Assert.AreEqual(1, result.Count);
}

İlk testimizde inputSize olarak yani kaç çeşit renk tonu oluşturulacağını 1 olarak belirleyip, bize dönen listede 1 adet renk tonu oluştuğunu idda ediyoruz.

[Test]
public void Create_WithClassSize1_ReturnsSameColorInList()
{
    var inputColor = Colors.Red;
    var inputSize = 1;

    ColorToneCreator creator = new ColorToneCreator();

    var result = creator.Create(inputColor, inputSize);

    Color color = result[0];

    Assert.AreEqual(255, color.R);
    Assert.AreEqual(0, color.G);
    Assert.AreEqual(0, color.B);

}

İkinci testimizde ise yine 1 çeşit renk tonuna karşılık oluşan rengin RGB değerlerinin ne olacağını idda ediyoruz. Kırmızı rengi gönderdiğimiz için R=255, G=0, B=0 olarak bize geri dönecektir.

[Test]
public void Create_WithClassSize2_ReturnsColorsInList()
{
     var inputColor = Colors.Red;
     var inputSize = 2;

     ColorToneCreator creator = new ColorToneCreator();

     var result = creator.Create(inputColor, inputSize);

     Color color = result[0];

     Assert.AreEqual(255, color.R);
     Assert.AreEqual(0, color.G);
     Assert.AreEqual(0, color.B);

     Color color2 = result[1];

     Assert.AreEqual(255, color2.R);
     Assert.AreEqual(127, color2.G);
     Assert.AreEqual(127, color2.B);
}

Üçüncü testimizde ise kırmızı renge ait iki farklı ton seçeneğini test ediyoruz. Ortaya çıkan iki renkten birincisi için RGB değerleri R=255, G=0, B=0 şeklinde iken ikincisi için R=255, G=127, B=127 şeklinde olacaktır. En yüksek değer 255 olduğundan eşit dağılım olması açısından 255 değeri renk tonu sayısına bölünerek değerler hesaplanmaktadır.

Buraya kadar gelişen test sürecinden üretilen kod ise şu şeklide olacaktır.

public class ColorToneCreator
{
     public List<Color> Create(Color inputColor, int inputSize)
     {
          int rgbFactor = 0;
          int incFactor = 255 / inputSize;

          List<Color> tones = new List<Color>();

          for (int i = 0; i < inputSize; i++)
          {
             byte r = (byte)(inputColor.R + rgbFactor > 255 ? 255 : inputColor.R + rgbFactor);
             byte g = (byte)(inputColor.G + rgbFactor > 255 ? 255 : inputColor.G + rgbFactor);
             byte b = (byte)(inputColor.B + rgbFactor > 255 ? 255 : inputColor.B + rgbFactor);

             tones.Add(Color.FromArgb(255, r, g, b));
             rgbFactor += incFactor;
          }

          return tones;
     }

}

Test sürecinden gelişen üretim kodu bu şeklide oluştuğuna göre artık geriye sadece bu kodu bir uygulama içerisinde kullanmak kallıyor.

Bu kodun kullanılacağı uygulamayı ise WPF uygulaması olarak seçiyoruz. Solution penceremize ColorManagerGUI adında yeni bir WPF projesi ekleyerek devam edebiliriz.

colorUnitTest3

Yeni solution penceresi yukarıdaki şeklinde olacaktır. WPF uygulaması MVVM deseni ile geliştirilmiştir. MainWindow.xaml view penceresinin DataContext’i için MainWindowModel şeklinde bir model sınıfı oluşturulmuştur. Bu sayede kod tarafı ile xaml tarafı birbirinden ayrılmış oldu.

Görüntü katmanında gelişen olaylar, form tasarımı ve bir butona tıklayarak parametrelerin, ColorManager tipine gönderilmesi şeklinde gelişmektedir. Aynı şekilde dönen rek tonları da formda bir ListBox içerisine yerleştirilmektedir.

Uygulamanın kaynak kodlarını ekte sunulmaktadır. Bu yüzden görüntü katmanını uzun uzun anlatmaya gerek duymadım. Zaten burada asıl vurgulanmak istenen, renk tabanlı bir uygulamanın test güdümlü olarak nasıl geliştirildiğidir.

Anafikir:

Bu örnek uygulamada renk tabanlı test güdümlü bir süreç işletilmiştir. Bu yöntemden yola çıkılarak görüntü işleme uygulamaları da test güdümlü olarak gelişitirilebilir. Bellek üzerine döşenmiş bir Bitmap nesnesi üzerinden de RGB tabanlı olarak test güdümlü geliştirmeler yapmak mümkün hale gelmektedir.

Örnek Uygulama:

Kodlara buradan ulaşabilrisiniz.

Testin Gücü

2 Oca

Bu yazıda, Test Driven Development (TDD) ile proje geliştirmenin faydalarından bahsetmeye çalışacağım.

Aşağıdaki resimde bir web projesine ait test sonuçlarını görmekteyiz. Bu test sonuçlarına göre 310 adet test başarılı bir şeklide sonuca ulaşmış(passed) durumda. Testlerin toplam süresi ise sadece 9 saniye.

TestExplorer

Hazırladığım bu proje bir Asp.Net MVC projesidir ve tamamen test edilmeye uygun ve gelişime açık bir şekilde yazılmıştır. Yani  Open Closed prensibine uyulmuştur.

Bu şeklide proje hazırlamanın bize ne gibi faydası olabilir?

Projemizi hiç çalıştırmadan ve web arayüzü oluşturmadan, proje iskeletinin nasıl çalıştığını görebilmekteyiz. Örneğin elimizde hiç web formu bile yokken bir ürün ekleme sınıfının POST ile gelen ürünleri veritabanına ekleyip ekleyemediğini anlayabilmekteyiz. Ekleme, silme güncelleme işlemlerini yapan controller sınıflarını ve action metodlarını, view sayfalarına ihtiyaç duymadan test edebilmekteyiz. Bu sayede iş katmanını tasarım katmanından rahat bir şekilde ayırabilmekteyiz.

Bir diğer önemli özellik ise mocking diye adlandırılan taklit edilmiş nesnelerle çalışabilmektir. Gerçek verilerin veritabanından alınıp test edilmesi biraz uzun bir süreç olabilir. Veritabanınız uzakta olabilir. Ya da test makinesinden erişime kapalı olabilir. Bu gibi durumlarda, veritabanı tablolarını, kendi oluşturduğumuz nesnelerle temsil ederek çalışmak zorunda kalırız. Kendi hazırladığımız nesneleri, veritabanından geliyormuş gibi controller sınıflarına gönderebiliriz. Bu sayede çok hızlı bir sonuç alabiliriz. Test sırasında yüzlerce metodun veritabanı bağlantısını açıp, veri alıp sonra bağlantı kapattığını düşünecek olursak, test süresinin dakikalar alabilieceğini öngörebiliriz. Oysa yukarıdaki test sonucunda taklit (mock) nesneler kullanarak test sonucunun saniyelere indiğini görebilmekteyiz.

CodeCoverage2

TDD yaklaşımı sayesinde hiç teste girmemiş kodumuz olup olmadığını görebilmekteyiz. Hatta bir metodun içerisindeki bir sınamanın bile testten geçip geçmediğini anlayabilmekteyiz. Yukarıdaki resimde Controller sınıflarına ait kod kapsam(code coerage) bilgileri yer almaktadır. Amaç %100 kod kapsamını yakalamaktır. Eğer yakalayamıyorsak, kodlarımızda ya teste uymayan bir mimari vardır ya da testten geçirmeyi unuttuğumuz testler vardır. Yukarıdaki tabloda Not Covered (%Blocks) sütununun sıfırlanırken, Covered(%Blocks) sütunun 100’e çıkarıldığını görüyoruz. Hedefe tam anlamıyla ulaşmış bulunuyoruz.

Umarım TDD adına faydalı bir yazı olmuştur. Bir sonraki yazıda görüşmek dileğiyle.

Math Operations (Matematiksel) Kata .Net

19 Kas

Matematiksel işlemler katası

Bu katanın amacı, değişkenleri ve sabitleri belli olan matematiksel formülleri çözebilen bir uygulama geliştirmek.

Örnekler / Examples
————————————————-

1 + 1 => constant + constant
x + y => variable + variable
x + y -1 => variable + variable + constant
(x+y) / 2 =>(variable + variable) / constant
(x*y)-(x/3)=>(variable + variable) – (variable/3)

Microsoft .Net ortamında geliştirilmiş ve Test Driven Development kuralları uygulanmış olan bir kod katasıdır.

Kaynak kodlara github hesabımdan ulaşabilirsiniz.

Not: Bu katada geliştirilen Math Expression örneği, “The C# Programming Language” kitabındaki bir bölümden esinlenerek yapılmıştır.

Tekrar görüşmek dileğiyle.

FizzBuzz Kata NCrunch ve NUnit tools

11 Kas

FizzBuzz Kata

FizzBuzz uygulaması, girilen parametrelerden

3 ile bölünebilen sayılar için sonuç Fizz
5 ile bölünebilen sayılar için sonuç Buzz
3 ve 5 ile bölünebilen sayılar için sonuç FizzBuzz
Ne 3 ile ne de 5 ile bölünebilen sayılar için sayının kendisini veren bir birim test pratiğidir.

Unit Test Assert List

1- Result_ForDivisibleByThree_IsFizz
2- Result_ForDivisibleByFive_IsBuzz
3- Result_ForDivisibleByBothThreeAndFive_IsFizzBuzz
4- Result_ForDivisibleNeitherThreeNorFive

Yukarıda birim testlerin listesi çıkarılmıştır ve bu listeye göre testler icra edilmektedir.

NOT: Makinemdeki donanım (işlemci) yetersizliğinden dolayı hem görüntü kaydı hemde Visual Studio’nun çalışması sırasında NCrunch aracı eş zamanlı derlemelerde biraz yavaş kaldı. Çünkü video kaydı başlar başlamaz işlemci %100’lere dayandı.

Tekrar görüşmek dileğiyle.

NCrunch Visual Studio Eklentisi

6 Kas

NCrunch, kodlama esnasında birim testleri (unit tests) otomatik ve eş zamanlı olarak çalıştıran bir Visual Studio eklentisidir.

Projelerini teste dayalı geliştirenler için mükemmel bir araç diyebilirim. Performans konusunda donanımınızın yeterliliğine ve test sayınıza göre NCrunch analiz süresi değişiklik gösterebilir.

NCrunch aracı, siz kodunuzu yazarken arka planda otomatik olarak kodu testlerden geçirerek durumu size bildirir.

İsterseniz testleri otomatik olarak değil de el yordamıyla da yaptırabilirsiniz. Testlerin durumunu aşağıdaki pencereden de görebilirsiniz.

Büyük projeler düşünülerek, Visual Studio IDE performansı üzerindeki etkileri en aza indirmek için, proje mimarisindeki bağımlılıkları analiz ederek,  testleri yürütme işlemi için öncelik sırasına koyar ve asenkron süreçler, ek işlemci çekirdeği kullanır.

Bir diğer özellik ise test kapsamına girmeyen kodların belirlenmesidir.

Siyah noktayla işaretlenen satırların test edilmediğini anlayabilmekteyiz. Yeşil noktayla işaretlenen kod satırlarının testlerden başarıyla geçtiğini göstermektedir.

Testlerin çalıştırılma süresini ölçen özelliği sayesinde ise uzun sürebilecek testler işaretlenir.

NCrunch aracının noktasal işaretleme özelliğinin renkleri isteğe göre değiştirilebilmektedir.

Test Driven Development yapanlar için çok iyi bir araçtır.

Visual Studio code coverage özelliğini açmak

12 Tem

Visual Studio 2010 üzerinde geliştirdiğimiz Test Driven uygulamalrı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.

Code coverage özelliğini açmak için şu adımları izlemeliyiz:

  1. Solutution Explorer penceresindeki [Local].testsettings dosyasına çift tıklayın.
  2. Açılan “Test Settings” dialog penceresinde, “Data and Diagnostics”  menüsünü seçin.
  3. Açılan listede, “Code Coverage” [Resim 1] seçerek ‘”Configure” butonuna tıklayın.
  4. “Code Coverage Detail” [Resim2] penceresinden kod kapsamını merak ettiğiniz assembly yi seçin.
  5. Testinizi çalıştırın ve “Test Tools” toolbar içerisindeki “Code Coverage Results” seçeneğinden sonucu inceleyin.
Resim-1
Resim-2

Test Driven Development’a doğru

18 Haz

Programlamaya başlayan herkes, önce hiçbir kurala dikkat etmeden “Run” tuşuna basarak istediği sonucu görmek ister. Bu doğaldır çünkü öğrenmeye yeni başlayan bir programcı adayının tüm işleyiş hakkında detaylı bir bilgisi yoktur. Zaman ilerledikçe fonksiyon, metod, struct, class gibi yapıları öğrenmeye başlar. Öğrendiği yapıları severek uygulamr ve “Oh be ne rahatlık varmış” der. Artık uzun satırlar halinde yazıdığı karmaşık kodları sınıflara, metodlara bölerek yazmaya başlamıştır.

İşi biraz daha ilerleten programcımız daha önce hiç duymadığı bir kavram olan nesneye dayalı programlamayı (Object Oriented Programming) karşısında görür. Neyneya dayalı programlamanın temeli olan Encapsulation(Kapsam), Inheritence(Miraslama) ve Polimorphism(Çok biçimlilik) kavramlarını öğrenir ve “Meğer ben daha önceleri kod yazmıyormuşum.” der. Nesneye yönelik programlama, geliştirilen kodun dış dünya ile izolasyonunu sağlar ve kodda bazı kısıtlamalar yapmaya olanak sunar. Bu sayede yazılımcının geliştirdiği kodu kullanan diğer geliştiriciler, kendilerini ilgilendirmeyen mahrem kodları görmezler ve kafa karışıklığı yaşamazlar. Ayrıca görülmemesini istediğimiz algoritmalar varsa private erişim belirleyiciler ile dış dünyadan gizleyebilirler. Kısaca nesneye dayalı programlama, geliştirilen API üzerinde bazı kısıtlamalar yapmaya ve API içerisinde gerekli durumlarda miraslama ile hiyerarşik yapının kurulmasına olanak sağlanmış olur. Artık programcı, ikinci adım olan nesneye dayalı programlamayı da öğrenmiştir ve uygulamaya başlamıştır.

Bir süre sonra programcı, Test Driven Development(TDD) kavramıyla karşılaşır. Programcının kodlama geçmişine aykırı, kodlama mantığını ve kodlama biçimini kökten değiştirecek yeni bir akımdır bu. Alışılagelmiş şelale(Waterflow) tarzı kod geliştirmeyi reddeden, önce testin yazılmasını gerektiren ve testten başarıyla geçen konun düzenlenerek üretime katılmasını sağlayan bir yöntemdir. Programcı, TDD mantığını öğrendiğinde, ya onu çok sever ya da ondan nefret eder. Ortası yoktur bu işin. Çünkü kodun bir kısmı test edilebilir, bir kısmı teste uymayan şekilde yazıldığında çelişkiler yumağı oluşmaya başlar.

Genelde TDD iyi öğrenilmediği taktirde, saçma sapan bir iş olduğu düşünülerek terk edilir. Ama işin aslı öyle değildir. Sanılanın aksine TDD, çok gerekli ve yazılımın başarıya ulaşması için önemli bir yöntemdir.   Koda olan güveni arttırır. Başarılı sonuç almaya daha yatkın bir yöntemdir. Geleneksel yazılım yöntemleriyle başlatılan projelerin %50’den azının başarıya ulaştığı bir ortamda, denemeye değer bir yöntem olduğu açıktır.

Geleneksel yöntemlerle başarıya ulaşan projelerin sayısının az olmasının sebebi nedir? Sebeplerin en başında, ürünün sürekli gelişen bir yapıda olduğunun göz ardı edilmesi gelmektedir. Gelişim varsa değişimde vardır. Sürekli değişimin kaçınılmaz olduğu bir projede her şeyi önceden kestirilmeye çalışımak, sonu belli olmayan bir maceraya atılmak gibidir. Hal böyle olunca, yöntemde bir sorun olduğu ortaya çıkmaktadır.

Test edilmeyen kodların birbirini nasıl etkilediği, davranışlarının nasıl olduğu bilinmediğinden, zamanla kod kırlmaları yaşanmaya başlayar. Aslında geleneksel yöntemlerde de test işlemi yapılmaktadır. Ancak bu test işlemi, özel bir test geliştirme aracıyla değil yazılımcının geliştirdiği arayüzlerle v.s yapılmaktadır. TDD yönteminde ise kodların davranışları önce bir test aracından geçirilir, üretilen kodlar kullanıma hazır bir şeklide uygulama ortamına sunulmaktadır.

Bu arada test driven development ile geliştirme yapanlar, önce test yazıp sonra kod üretimi yapak zorunda da değildir. Kodu yazdıntan sonra da test sınıflarını yazanlar var. Ancak bu yöntem TDD geleneğine uygun bir yöntem değildir

Özetle test driven development, geleneksel yöntemlerin dışında bir tekniktir. Bu tekniğe alışmak biraz zordur. Çünkü bu yöntem sağ elimizle yapmaya alıştığımız işleri, sol elimizle yapmaya zorlar gibidir. Önce kodu yazıp sonra ara yüzümüzde test etmek yerine, önce testi yazıp sonra testten geçen kodları çalışan kod olarak kullanırız.

Bu yöntem çevik(agile) süreçlerin de önem kazandığı günümüzde çoğu yazılımcının gözdesi haline gelmiştir. Büyük yazılım şirketlerinin de vazgeliçmez yöntemidir.

ASP.NET MVC Controller Test Ortamında UpdateModel Davranışları

4 Mar

Bu yazıda ASP.NET MVC ortamında test sınıflarımı hazırlarken karşılaştığım küçük bir ayrıntıyı analtmak istiyorum.  Bu noktadan itibaren kullanacağım örnek ASP.NET MVC3 ortamında yürütülen Nerddinner projesindeki Edit action metod testi olacaktır. Neden Edit action metodunu test ediyorum? Bunun sebebi Edit işlemi sırasında Controller temel sınıfının helper metodları olan UpdateModel veta TryUpdateModel metodlarının özel bir durumunun olması.

UpdateModel helper metodu, form ortamında bir bilgi güncellemesi yapıldığında, formdan  post yöntemi ile gelen değerleri ilgili nesneye bağlamak için kullanılır. Aşağıdaki örnekte görüldüğü üzere FormCollection içierisinden gelen form bilgileri, UpdateModel(dinner) ile dinner nesnesini güncellemektedir.


[HttpPost, Authorize]
public ActionResult Edit(int id, FormCollection collection) {

       Dinner dinner = dinnerRepository.Find(id);

       if (!dinner.IsHostedBy(User.Identity.Name))
            return View("InvalidOwner");

       try {
            UpdateModel(dinner);
            dinnerRepository.Save();
            return RedirectToAction("Details", new { id=dinner.DinnerID });
       }
       catch {
            return View(dinner);
       }
}

O halde bu noktadan sonra şunu anlıyoruz ki test ortamında da UpdateModel metodunu kullanan metodların testi için FormCollction nesnesi kullanmalıyız. Bu güncelleme işlemi nasıl yapılmaktadır? UpdateModel tarafından  Controller sınıfının “ValueProvider” özelliğine bir FormCollection nesnesi atanarak yapılmaktadır.

[TestMethod]
public void EditAction_Should_Redirect_When_Update_Successful() {

      // Arrange
      var controller = CreateDinnersControllerAs("SomeUser");
      int id = 1;

      FormCollection formValues = new FormCollection() {
         { "Dinner.Title", "Another value" },
         { "Dinner.Description", "Another description" }
      };

      controller.ValueProvider = formValues.ToValueProvider();

      // Act
      var result = controller.Edit(id, formValues) as RedirectToRouteResult;

      // Assert
      Assert.AreEqual("Details", result.RouteValues["Action"]);
      Assert.AreEqual(id, result.RouteValues["id"]);

}

Dikkat: FormCollection kullanılmayan test metodları UpdateModel metodunun çalıştırılması(invoke) sırasında NullReferenceException hatası verecektir.

Soru: Eğer Edit action metoduna parametre olarak FormCollection değilde nesnenin kendisi atılsaydı veya bir ViewModel patterne sahip bir nesne gönderilirse ne oladak?

DinnerFormViewModel adında bir nesne ve bu nesne içinde de Dinner tipinde Dinner adında bir property olduğunu varsayalım.


[HttpPost, Authorize]
public ActionResult Edit(int id, DinnerFormViewModel model) {

       Dinner dinner = dinnerRepository.Find(id);
       if (!dinner.IsHostedBy(User.Identity.Name))
            return View("InvalidOwner");

       try {
            UpdateModel(dinner, "Dinner");
            dinnerRepository.Save();
            return RedirectToAction("Details", new { id=dinner.DinnerID });
       }
       catch {
            return View(dinner);
       }
}

Bu durumda UpdateModel metodunun, prefix(ön ek) belirlenebilen versiyonunu kullanıyoruz. Yani DinnerFormViewMolel içerisindeki “Dinner” ile başlayan nesneler “ValueProvider” Property’sine bağlanacak.