NUnit, Visual Studio 2008'in Birim Testi için Test Projeleri mi? [kapalı]

İş yerinde yeni bir proje başlatacağım ve birim testlerine girmek istiyorum. VS 2008, C # ve ASP.NET MVC öğelerini kullanacağız. NUnit ya da VS2008'in yerleşik test projelerini kullanmaya bakıyorum, ancak diğer önerileri araştırmaya açığım. Bir sistem diğerinden daha iyi veya kullanımı / anlaşılması diğerinden daha kolay mı? Bu projeyi, geliştirme çabalarımız için bir tür "en iyi uygulama" olarak ayarlamak istiyorum.

Herhangi bir yardım ve öneri için teşekkürler !!

Daok , VS2008 test projelerinin tüm profesyonellerini seçti, burada NUnit'in profesyonelleri.

• NUnit'in alaycı bir çerçevesi var.
• NUnit IDE dışında çalıştırılabilir, CC.Net gibi MS olmayan bir sunucuda sınama yapmak istiyorsanız bu yararlı olabilir
• NUnit'in görsel stüdyodan daha fazla sürümü var. Yeni bir sürüm için yıllarca beklemek zorunda değilsiniz ve yeni özellikler elde etmek için IDE'nin yeni bir sürümünü yüklemenize gerek yok.
• NUnit için satır testleri vb.Gibi geliştirilmekte olan uzantılar vardır.
• Visual Studio sınamalarının bir nedenle başlatılması uzun zaman alır. Bu 2008'de daha iyi ama benim zevkime göre hala çok yavaş. Bir şeyi kırıp kırmadığınızı görmek için hızlı bir şekilde test yapmak çok uzun sürebilir. NUnit Testdriven.Net gibi bir şey ile IDE testleri çalıştırmak için aslında çok daha hızlı. özellikle tekli testler yaparken.
  Kjetil Klaussen'e göre bunun nedeni Visual Studio test runner'ıdır, TestDriven.Net'te MSTest testleri çalıştırmak MSTest performansını NUnit ile karşılaştırılabilir hale getirir.

Birim sınama çerçevesi aslında önemli değildir, çünkü ayrı proje dosyaları ve koşullu derleme ile test sınıflarını dönüştürebilirsiniz (bunun gibi VS-> NUnit):

 # if! NUNIT
  Microsoft.VisualStudio.TestTools.UnitTesting kullanarak;
 #Başka
  NUnit.Framework kullanarak;
  TestClass = NUnit.Framework.TestFixtureAttribute kullanarak;
  TestMethod = NUnit.Framework.TestAttribute kullanarak;
  TestInitialize = NUnit.Framework.SetUpAttribute kullanarak;
  TestCleanup = NUnit.Framework.TearDownAttribute kullanarak;
  using TestContext = System.String;
  deploymentItem = NUnit.Framework.DescriptionAttribute kullanarak;
 #endif

TestDriven.Net eklentisi hoş ve çok pahalı değil ... Sadece düz VS2008 ile testi test sınıfınızdan veya test listenizden bulmanız gerekir. TestDriven.Net ile testinizi doğrudan test ettiğiniz sınıftan çalıştırabilirsiniz. Sonuçta, birim testinin bakımı kolay ve geliştiricinin yakınında olmalıdır.

VS2008 Yerleşik Birim Test Çerçevesinin avantajları / değişiklikleri

1. 2008 sürümü artık profesyonel sürümlerde (VS'nin pahalı sürümlerine ihtiyaç duymadan önce, bu sadece geliştirici birimi testi içindir.) Birçok geliştiriciyi açık / harici test çerçevelerinin tek seçeneğiyle bıraktı.
2. Tek bir şirket tarafından desteklenen dahili API.
3. Testleri çalıştırmak ve oluşturmak için aynı araçları kullanın (bunları MSTest komut satırını kullanarak da çalıştırabilirsiniz)
4. Basit tasarım (Mock çerçevesi verilmemiştir, ancak bu birçok programcı için harika bir başlangıç ​​noktasıdır)
5. Uzun süreli destek verildi (nDoc'a ne olduğunu hala hatırlıyorum, 5 yıl içinde desteklenmeyecek bir test çerçevesine girmek istemiyorum, ancak yine de nUnit'i harika bir çerçeve olarak görüyorum.)
6. Takım temel sunucunuzu arka uç olarak kullanıyorsanız, başarısız test verileriyle basit bir şekilde iş öğeleri veya hatalar oluşturabilirsiniz.

2 yıldır NUnit kullanıyorum. Her şey yolunda ama VS birim sistemi oldukça güzel olduğunu söylemek zorundayım çünkü Gui içinde ve daha kolay karışıklık yapmadan özel işlev için test yapabilirsiniz. Ayrıca, VS'nin Birim Testi, NUnit'in tek başına yapamayacağı kaplama ve diğer şeyleri yapmanıza izin verir.

Visual Studio'nun test çerçevesinin hafif bir sıkıntısı, proje dizininizi karmaşık hale getiren birçok test çalıştırması dosyası oluşturmasıdır - ancak bu büyük bir anlaşma değildir.

Ayrıca, TestDriven.NET gibi bir eklentiye sahip değilseniz, NUnit (veya MbUnit, xUnit vb.) Birim sınamalarınızda, yerleşik Microsoft VS sınama çerçevesi ile olduğu gibi Visual Studio ortamında hata ayıklayamazsınız.

Biraz konu dışı, ancak NUnit ile giderseniz ReSharper'ı kullanmanızı tavsiye edebilirim - VS UI'ye IDE içinden testleri çalıştırmayı ve hata ayıklamayı çok daha kolay hale getiren bazı düğmeler ekler.

Bu inceleme biraz güncel değil, ancak bunu daha ayrıntılı olarak açıklıyor:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx

XUnit, bir yeşil alan projesi için başka bir olasılık. Belki daha sezgisel bir sözdizimine sahiptir, ancak diğer çerçevelerle gerçekten uyumlu değildir.

http://www.codeplex.com/xunit

NUnit üzerinden VS birim testleri ile benim ana sığır VS testi oluşturma özel üye erişimi için oluşturulan bir kod enjekte eğilimindedir olduğunu.

Bazıları özel yöntemlerini test etmek isteyebilir, bazıları olmayabilir, bu farklı bir konudur.

Benim endişem birim testleri yazarken son derece kontrol edilmelidir bu yüzden tam olarak ne test ve tam olarak nasıl test biliyorum. Otomatik oluşturulan kod varsa bu sahipliğin bir kısmını kaybediyorum.

Her ikisini de kullanarak bir TDD yaptım ve (belki biraz aptalım) nUnit benim için çok daha hızlı ve basit görünüyor. Ve çok şey söylediğimde, çok şey demek istiyorum.

MS Testinde, her yerde çok fazla özellik var - gerçek testleri yapan kod, burada ve orada okuyabileceğiniz küçük satırlardır. Büyük bir karmaşa. NUnit'te, testi yapan kod, niteliklere, olması gerektiği gibi hakimdir.

Ayrıca, nUnit'te, sadece çalıştırmak istediğiniz testleri tıklamanız yeterlidir (sadece bir? Bir sınıfı kapsayan tüm testler? Montaj? Çözüm?). Tek tık. Ve pencere açık ve geniş. Açık yeşil ve kırmızı ışıklar alıyorsunuz. Bir bakışta ne olduğunu gerçekten biliyorsun.

VSTS'de test listesi ekranın altında sıkıştı, küçük ve çirkin. Ne olduğunu bilmek için iki kez bakmalısın. Ve sadece bir test yapamazsınız (henüz öğrenemedim!).

Ama yanlış olabilirim, elbette - "VSTS kullanarak basit TDD nasıl yapılır" hakkında 21 blog yazısı okudum. Daha fazlasını okumalıydım, haklısın.

NUnit için bir tane okudum. Aynı gün TDD yapıyordum. Eğlenceli.

Bu arada, genellikle Microsoft ürünlerini seviyorum. Visual Studio, bir geliştiricinin satın alabileceği en iyi araçtır - ancak Visual Studio Team System'deki TDD ve Work Item yönetimi gerçekten berbat.

Herşey gönlünce olsun. Sylvain.

"NUnit dosya yapısı VSTest daha zengin" iletiler var ... Elbette NUnit dosya yapısını tercih ederseniz, bu şekilde (NUnit-> VS) bu şekilde kullanabilirsiniz:

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

Ya da başka bir dönüşüm ... :-) Burada bu derleyici sadece takma adıdır.

Öncelikle yanlış bir ifadeyi düzeltmek istiyorum: msTest komutunu kullanarak visual studio dışında çalıştırabilirsiniz. TeamCity gibi birkaç CI aracı NUnit için daha iyi desteğe sahip olsa da (muhtemelen msTest daha popüler hale geldikçe değişecektir). Mevcut projemde hem kullandığımız hem de bulduğumuz tek büyük fark, mstest'in her zaman 32bit olarak çalıştığı, NUnit'in ise 32bit veya 64bit testi olarak çalıştığı ve sadece kodunuzun 32/64 bağımlı yerel kod kullanması durumunda önemli olduğu.

MSTest ile başladım ama basit bir nedenden ötürü geçiş yaptım. MSTest, diğer yöntemlerden Test Yöntemlerinin Devralınmasını desteklemez.

Aynı testi birden çok kez yazma fikrinden nefret ettim. Özellikle test yöntemlerinin 100'lü testlere kolayca girebileceği büyük bir projede.

NUnit tam olarak ihtiyacım olanı yapar. NUnit ile eksik olan tek şey, her testin Kırmızı / Yeşil durumunu (VSTS gibi) görüntüleyebilen bir Visual Studio Eklentisidir.

.NET Test Framework Tavsiye ve .NET Birim Test paketleri? .

MSTest veya nUnit'i düşünüyorsanız, mbUnit'e bakmanızı tavsiye ederim. Nedenlerim

1. TestDriven.Net uyumluluğu. Hiçbir klavye testi kombinasyonuna TestDriven.Net.ReRunWithDebugger bağlı değildir.
2. Gallio çerçevesi. Gallio nUnits gibi bir test koşucusudur. Tek fark, testlerinizi nUnit, msTest, xUnit veya mbUnit'te yazmanızın umurunda olmamasıdır. Hepsi kaçıyor.
3. NUnit ile uyumluluk. NUnit'teki tüm özellikler mbUnit tarafından desteklenir. Özelliklerinizi değiştirmeniz gerekmediğini düşünüyorum (bunu kontrol etmeniz gerekecek), sadece referansınızı ve kullanımlarınızı.
4. Koleksiyon ileri sürüyor. mbUnit, CollectionAssert sınıfı da dahil olmak üzere daha fazla Assert vakasına sahiptir. Temel olarak, 2 koleksiyonun aynı olup olmadığını görmek için artık kendi testlerinizi yazmanıza gerek yok.
5. Kombinatoryal testler. İki veri kümesi sağlayabilir ve tüm veri kombinasyonları için bir test alabilirseniz bu hoş olmaz mıydı. MbUnit içinde.

Başlangıçta onun [RowTest ....] işlevselliği nedeniyle mbUnit aldım ve geri dönmek için tek bir neden bulamadık. Tüm aktif test takımlarımı nUnit'ten taşıdım ve asla geriye bakmadım. O zamandan beri iki farklı geliştirme ekibini avantajlara dönüştürdüm.

Bildiğim kadarıyla, bu günlerde .NET ile birim testi için dört çerçeve mevcut

• NUnit
• MbUnit
• MSTest
• xUnit

NUnit her zaman öndeydi ama boşluk geçen sene içinde kapanmıştı. NUnit'i hala kendim tercih ediyorum, özellikle de bir süre önce akıcı bir arayüz eklediklerinden, testleri çok okunabilir hale getiriyorlar.

Birim testine yeni başlıyorsanız, muhtemelen çok fazla fark yaratmaz. Hız kazandıktan sonra, hangi çerçevenin ihtiyaçlarınız için en iyi olduğunu değerlendirmek için daha iyi bir konumda olacaksınız.

VS yerleşik test çerçevesini sevmiyorum çünkü testlerinizi test ettiğiniz projenin bir parçası olarak yapmak yerine ayrı bir proje oluşturmaya zorluyor.

MSTest, NUnit'in birkaç yeni özelliği (montaj ve sökme, sadece fikstür ve test seviyesi gibi değil) ve en iyi bitlerden bazılarını (yeni 2.4 kısıtlama sözdizimi gibi) eksik olarak yeniden işledi. NUnit daha olgun ve diğer satıcılardan daha fazla destek var; ve elbette her zaman ücretsiz olduğu için (MSTest bunu sadece 2008'in Profesyonel sürümüne yaptı, bundan önce daha pahalı SKU'lar oldu), çoğu ALT.NET projesi bunu kullanıyor.

Bunu söyledikten sonra, üzerinde Microsoft etiketi olmayan bir şey ve özellikle de OSS kodu kullanmak için inanılmaz derecede isteksiz olan bazı şirketler var. Dolayısıyla, resmi bir MS test çerçevesine sahip olmak, bu şirketlerin test yaptırması gereken motivasyon olabilir; ve dürüst olalım, kullandığınız araç değil, önemli olan testtir (ve yukarıdaki Tuomas Hietanen kodunu kullanarak test çerçevenizi neredeyse değiştirilebilir yapabilirsiniz).

Kod Sözleşmeleri sisteminin .NET 4.0 sürümünde ve statik denetleyicinin kullanılabilirliğiyle , teorik olarak daha az sınama vakası yazmanız gerekir ve Pex gibi bir araç bu durumları tanımlamaya yardımcı olur. Eldeki tartışmayla ilgili olarak, birim testlerinizle daha az şey yapmanız gerekiyorsa, sözleşmeleriniz kuyruğunuzu kapsıyorsa, neden sadece devam edip yerleşik parçaları kullanmıyorsunuz, çünkü bu yönetilmesi daha az bağımlılıktır. Bugünlerde tamamen sadelik ile ilgiliyim. :-)

Ayrıca bakınız:

• Microsoft Pex - Otomatik Birim Testi
• Visual Studio 2010 ve C # 4.0 kullanarak Pex ile Birim Testleri oluşturma

MS'in küçük test çerçevesini kullanmayı tercih ederim, ancak şimdilik NUnit ile bağlı kalıyorum. MS'lerle ilgili sorunlar genellikle (benim için)

• Bakımı gereken paylaşılan "testler" dosyası (anlamsız)
• Test listeleri birden çok geliştirici / VCS ile çakışmaya neden olur
• Kötü entegre kullanıcı arayüzü - kafa karıştırıcı kurulum, külfetli test seçimi
• İyi harici koşucu yok

Uyarılar - Bir aspx sitesini test ediyor olsaydım, kesinlikle MS'leri kullanırdım - Yalnız geliştiriyor olsaydım, MS de iyi olurdu - Sınırlı yeteneğim olsaydı ve NUnit'i yapılandıramazsam :)

Sadece testlerimi yazmak ve NUnitGUI veya diğer ön uçlardan birini ateşlemek çok daha kolay buluyorum (testDriven çok uzaklara pahalı). Komut satırı sürümü ile hata ayıklamayı ayarlamak da oldukça kolaydır.