Alaycı Çerçeve seçiminde anahtar faktörler nelerdir?

Birim testlerimdeki nesnelerle çalışmaya başlamak istiyorum. Görünüşe göre tonlarca iyi alaycı çerçeve var.

1. Farklı çerçevelerin farklı hedef kitleleri var mı?
2. Durumum için hangi çerçevenin doğru olduğunu seçerken hangi faktörleri göz önünde bulundurmalıyım?

Farklı çerçevelerin farklı hedef kitleleri var mı?

Evet. Microsoft Moles , TypeMock Isolator ve JustMock gibi bazı çerçeveler , hemen hemen her şeyi alay edebilmenizi sağlar. Bu alay araçları genellikle mevcut eski kodda kullanmak isteyen geliştiriciler için daha iyidir, çünkü daha test edilebilir bir tasarıma yeniden odaklanmak mümkün olmayabilir. *

Geleneksel olarak test edilebilir tasarımlar, kod tabanının arayüzleri, soyut sınıfları, sanal yöntemleri, mühürsüz sınıfları vb. Liberal olarak kullanması gerektiği anlamına gelir. Bu nedenle, Moq ve RhinoMocks gibi geleneksel alaycı çerçeveler Test Güdümlü Geliştirme, Bağımlılık Enjeksiyonu ve bu tür diğer kavramlar. Bu arada, test edilebilir koddan çok daha fazlasını elde ettiğiniz için Bağımlılık Enjeksiyonunu kullanmanızı şiddetle tavsiye ederim, ancak daha sürdürülebilir kod da.

Durumum için hangi çerçevenin doğru olduğunu seçerken hangi faktörleri göz önünde bulundurmalıyım?

• Geliştirme Faaliyeti. Moq ve RhinoMocks gibi araçlar çok aktif ve popülerdir ve bu nedenle günceldir.
• Açık Kaynak Vs. Ticari . Bu karşılaştırma için tipik olan çeşitli artıları ve eksileri düşünün. Maliyet, Destek vb.
• Olgunluk. Araç ne kadar yeni. Beta sürümündedir (Microsoft Moles gibi) veya birkaç kararlı sürümü var mı? Örneğin, eski kod için Moles'i seviyorum, ancak içinde ele alınması gereken birkaç hata var ve bunlar ele alınmadan önce beklemek olacak (bir sonraki sürüm Kasım 2011).
• Belgeler. Birim testi, alay etme, otomatik alay etme vb. Konularını içeren birkaç kitap ve blog vardır. Ayrıca aracın kendi dokümantasyonu ne kadar iyi?
• Sözdizimi . Her aracın aynı şeyi söylemenin kendine özgü bir yolu vardır. Hangisinin sizin için daha uygun olduğunu görün.
• Hız . CLR profili kullanan araçlar (TypeMock, Moles, JustMock), geleneksel olanlardan çok daha yavaş olabilir (Adedi, RhinoMocks). Bu hız cezası, birçok birim testi topladığınız için bir sorun olabilir. Temel kural, bir testin saniyede 1/10'dan daha uzun sürmesi durumunda çok yavaş olmasıdır.
• Topluluk Desteği . Diğer geliştiriciler alay aracına uzanan (veya iltifatta çalışan) başka araçlar yazıyor mu? Moq'a otomatik alay etme yeteneği ekleyen bir Moq.Contrib projesi vardır (bu da test yazma süresini hızlandırmaya yardımcı olur). Daha da iyisi, AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks vardır, bu da Otomatik alay ve artı anonim değişken oluşturmaya izin verir.

^{* Geleneksel test (ve alaycı) araçlarıyla kullanılabilecek koda testler olmadan kodu yavaşça yeniden düzenleme yolları için bkz . Eski Kod ile Etkili Çalışma .}

Moq öğretici Typemock İzolatörler, RhinoMocks ve Adedi: birkaç belirli araçları ile ilgili olarak bu anlatılır başında arka, felsefe ve tartışmalara sağda bir bölüm vardır. Adedi açıklamak için yazılmıştır, bu yüzden doğal olarak biraz çarpık, ama alaycı çerçevelerdeki bazı farklılıkları anlamaya çalışırken benim için oldukça yararlı buldum.

C # Mocking Frameworks bu SO iş parçacığının yanıtlarını da yararlı buldum . Çoğu, kullanıcının gerçekten yararlı bulduğu bir Mocking Çerçevesine atıfta bulunur, ancak HaraldV'den proxy tabanlı alaycıları ve profiler tabanlı alaycıları tartışan bir yol vardır.

Ayrıca çevrimiçi olarak bir karşılaştırma tablosu bulabildim. 2009'dan beri olduğunu unutmayın, bu yüzden güncel olduğundan emin değilim; TypeMock ve geri aramalar hakkındaki bilgilerin eski olduğunu belirten en az bir yorum var, ancak mevcut durumun ne olduğunu görmek için ayak işi yapmanız gerekse bile grafik, sorunları dikkate almak için iyi olabilir: RhinoMocks, Moq, NMock, ve TypeMock karşılaştırma tablosu

Google Code'da, kolay kod karşılaştırması için birden fazla alaycı çerçevede test senaryoları bulunan bir proje var: alay-çerçeveler-karşılaştır

1. Kullanım kolaylığı. Bazı çerçeveler daha gelişmiş kullanım deyimlerine sahiptir. Örneğin, MOQ , beklentileri kodlamak için lambdas kullanımına izin verir. Bazı eski kütüphaneler bunu desteklemez.
2. Hız. Her birim sınaması hızlı olmalıdır, böylece tüm kitaplığınızın çalışması saatler sürmez. Bazı alaycı çerçeveler, hızlı oluşturulan statik olarak oluşturulan alaylara sahiptir. Diğer çerçeveler çalışma zamanında dinamik olarak kod üretir, bu da daha yavaştır.
3. Destek. Düzeltmelerle etkin bir şekilde desteklenen ve yeni .NET sürümlerini desteklemek üzere güncelleştirildikleri bir çerçeve istiyorsunuz.
4. Güç. Araştırdığım alaycı çerçevelerin çoğu güç açısından kabaca aynı. Dikkate değer bir istisna vardır. Microsoft Moles "kapalı türlerde sanal olmayan / statik yöntemler" alay izin verir. Bu, başka hiçbir alaycı çerçevenin bildiklerime desteklemediği bir şey.

Ekibimde Microsoft Moles'i seçtik . # 2, # 3 ve # 4'te önemli ölçüde kazanır, ancak alternatiflerin çoğundan daha az deyimseldir ve # 1'in alt ucundadır.