Projekty testowe NUnit czy Visual Studio 2008 do testowania jednostkowego? [Zamknięte]

Zamierzam rozpocząć nowy projekt w pracy i chcę przejść do testów jednostkowych. Będziemy używać VS 2008, C # i ASP.NET MVC. Rozważam użycie NUnit lub wbudowanych projektów testowych VS2008, ale jestem otwarty na badanie innych sugestii. Czy jeden system jest lepszy od drugiego, a może łatwiejszy w użyciu / zrozumieniu niż drugi? Chcę, aby ten projekt został ustanowiony jako „najlepsza praktyka” dla naszych dalszych wysiłków rozwojowych.

Dzięki za wszelką pomoc i sugestie !!

Daok wymienił wszystkich pro projektów testowych VS2008, oto pro NUnit.

• NUnit ma frameworki.
• NUnit można uruchomić poza środowiskiem IDE, może to być przydatne, jeśli chcesz uruchomić testy na serwerze kompilacji innym niż MS, takim jak CC.Net
• NUnit ma więcej wersji niż studio graficzne. Nie musisz czekać lat na nową wersję I nie musisz instalować nowej wersji IDE, aby uzyskać nowe funkcje.
• Opracowywane są rozszerzenia dla NUnit, takie jak testy wierszy itp.
• Z jakiegoś powodu testy Visual Studio trwają długo. Tak jest lepiej w 2008 r., Ale wciąż jest zbyt powolny jak na mój gust. Szybkie uruchomienie testu, aby sprawdzić, czy coś nie popsuło, może zająć zbyt długo. NUnit z czymś takim jak Testdriven.Net do uruchamiania testów z IDE jest w rzeczywistości znacznie szybszy. szczególnie podczas wykonywania pojedynczych testów.
  Według Kjetil Klaussen jest to spowodowane przez testrunner Visual Studio, uruchomienie testów MSTest w TestDriven.Net sprawia, że ​​wydajność MSTest jest porównywalna z NUnit.

Struktura testowania jednostkowego nie ma większego znaczenia, ponieważ można konwertować klasy testowe za pomocą osobnych plików projektu i kompilacji warunkowej (np. VS-> NUnit):

 #if! NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #jeszcze
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #endif

Wtyczka TestDriven.Net jest ładna i niezbyt droga ... Z samym zwykłym VS2008 musisz znaleźć test z klasy testów lub listy testów. Dzięki TestDriven.Net możesz uruchomić test bezpośrednio z testowanej klasy. W końcu test jednostkowy powinien być łatwy w utrzymaniu i znajdować się w pobliżu dewelopera.

Korzyści / zmiany we wbudowanym systemie testowania jednostek VS2008

1. Wersja 2008 jest teraz dostępna w profesjonalnych wersjach (zanim wymagała drogich wersji VS, jest to tylko do testowania jednostek programistycznych). Pozostawiono wielu programistom jedyny wybór otwartych / zewnętrznych ram testowych.
2. Wbudowany interfejs API obsługiwany przez jedną firmę.
3. Użyj tych samych narzędzi, aby uruchomić i utworzyć testy (możesz je uruchomić przy użyciu wiersza polecenia, również MSTest)
4. Prosta konstrukcja (nie ma frameworku Mock, ale jest to świetny punkt wyjścia dla wielu programistów)
5. Udzielono długoterminowego wsparcia (wciąż pamiętam, co stało się z nDoc, nie chcę angażować się w ramy testowe, które mogą nie być obsługiwane za 5 lat, ale nadal uważam nUnit za świetny framework).
6. Jeśli używasz serwera Foundation Foundation jako zaplecza, możesz w prosty sposób tworzyć elementy pracy lub błędy z nieudanymi danymi testowymi.

Używam NUnit od 2 lat. Wszystko w porządku, ale muszę powiedzieć, że system jednostek w VS jest całkiem fajny, ponieważ znajduje się w GUI i może łatwiej wykonać test funkcji prywatnej bez konieczności bałaganu. Testowanie jednostkowe VS pozwala także na wykonywanie czynności obejmujących i innych rzeczy, których sam NUnit nie jest w stanie zrobić.

Niewielką irytacją frameworka testowego Visual Studio jest to, że utworzy on wiele plików uruchomień testowych, które mają tendencję do zaśmiecania katalogu projektu - choć nie jest to aż tak duże.

Ponadto, jeśli brakuje wtyczki, takiej jak TestDriven.NET, nie można debugować testów jednostkowych NUnit (lub MbUnit, xUnit itp.) W środowisku Visual Studio, jak to możliwe dzięki wbudowanemu środowisku testowemu Microsoft VS.

Nie na temat, ale jeśli korzystasz z NUnit, mogę polecić użycie ReSharper - dodaje kilka przycisków do interfejsu użytkownika VS, które znacznie ułatwiają uruchamianie i debugowanie testów z poziomu IDE.

Ta recenzja jest nieco nieaktualna, ale wyjaśnia to bardziej szczegółowo:

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

XUnit to kolejna możliwość dla projektu typu greenfield. Ma być może bardziej intuicyjną składnię, ale tak naprawdę nie jest kompatybilna z innymi frameworkami.

http://www.codeplex.com/xunit

Moja główna wołowina z testami jednostkowymi VS nad NUnit polega na tym, że tworzenie testów VS zwykle wstrzykuje wiązkę wygenerowanego kodu dla dostępu prywatnego członka.

Niektórzy mogą chcieć przetestować swoje prywatne metody, inni nie, to inny temat.

Obawiam się, że kiedy piszę testy jednostkowe, powinny one być bardzo kontrolowane, więc wiem dokładnie, co testuję i jak to testuję. Jeśli jest kod generowany automatycznie, tracę część tego prawa własności.

Zrobiłem trochę TDD przy użyciu obu i (może jestem trochę głupi) nUnit wydaje się być o wiele szybszy i prostszy w użyciu dla mnie. A kiedy dużo mówię, dużo mam na myśli.

W MS Test wszędzie jest zbyt wiele atrybutów - kodem wykonującym prawdziwe testy są małe linie, które możesz przeczytać tu i tam. Wielki bałagan. W nUnit kod wykonujący test dominuje atrybuty, tak jak powinien.

Ponadto w nUnit wystarczy kliknąć testy, które chcesz uruchomić (tylko jeden? Wszystkie testy obejmujące klasę? Zestaw? Rozwiązanie?). Jedno kliknięcie. A okno jest czyste i duże. Dostajesz jasne zielone i czerwone światła. Naprawdę wiesz, co dzieje się w jednym widoku.

W VSTS lista testów jest zablokowana w dolnej części ekranu, jest mała i brzydka. Musisz spojrzeć dwa razy, aby wiedzieć, co się stało. I nie możesz uruchomić tylko jednego testu (cóż, jeszcze się nie dowiedziałem!).

Ale oczywiście mogę się mylić - właśnie przeczytałem około 21 postów na blogu na temat „Jak zrobić proste TDD za pomocą VSTS”. Powinienem był przeczytać więcej, masz rację.

Dla nUnit czytam jeden. A ja byłem TDD tego samego dnia. Z zabawą.

Nawiasem mówiąc, zazwyczaj uwielbiam produkty Microsoft. Visual Studio jest naprawdę najlepszym narzędziem, jakie może kupić programista - ale TDD i zarządzanie elementami roboczymi w Visual Studio Team System jest do kitu.

Wszystkiego najlepszego. Sylvain.

Dostaję wiadomości, że „struktura plików NUnit jest bogatsza niż VSTest” ... Oczywiście jeśli wolisz strukturę plików NUnit, możesz użyć tego rozwiązania w inny sposób, na przykład (NUnit-> VS):

 #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

Lub dowolna inna konwersja ... :-) To użycie tutaj jest tylko aliasem dla kompilatora.

Najpierw chcę poprawić niepoprawne zdanie: możesz uruchomić msTest poza Visual Studio za pomocą wiersza poleceń. Chociaż kilka narzędzi CI, takich jak TeamCity, ma lepszą obsługę NUnit (prawdopodobnie zmieniłoby się, gdy msTest stałby się bardziej popularny). W moim obecnym projekcie używamy obu, a jedyną dużą różnicą, jaką znaleźliśmy, jest to, że mstest zawsze działa jako 32-bitowy, podczas gdy NUnit działa jako test 32-bitowy lub 64-bitowy, co ma znaczenie tylko wtedy, gdy Twój kod używa kodu natywnego, który jest zależny od 32/64.

Zacząłem od MSTest, ale zmieniłem z jednego prostego powodu. MSTest nie obsługuje dziedziczenia metod testowych z innych zespołów.

Nienawidziłem pomysłu napisania tego samego testu wiele razy. Zwłaszcza w dużym projekcie, w którym metody testowe mogą z łatwością przejść do setek testów.

NUnit robi dokładnie to, czego potrzebuję. Jedyne, czego brakuje w NUnit, to dodatek Visual Studio, który może wyświetlać status Czerwonego / Zielonego (jak VSTS) każdego testu.

.NET Framework Testing Advice i .NET Unit Testing pakiety? .

Jeśli zastanawiasz się nad MSTest lub nUnit, polecam przyjrzeć się mbUnit. Moje powody są

1. Kompatybilność z TestDriven.Net. TestyDriven.Net.ReRunWithDebugger nie są powiązane z kombinacją klawiszy.
2. Ramy Gallio. Gallio jest biegaczem testowym, jak nUnits. Jedyna różnica polega na tym, że nie ma znaczenia, czy testy zostały napisane w nUnit, msTest, xUnit lub mbUnit. Wszyscy uciekają.
3. Kompatybilność z nUnit. Wszystkie funkcje w nUnit są obsługiwane przez mbUnit. Myślę, że nawet nie musisz zmieniać swoich atrybutów (musisz to sprawdzić), tylko swoje referencje i zastosowania.
4. Kolekcja twierdzi. mbUnit ma więcej przypadków Assert, w tym klasę CollectionAssert. Zasadniczo nie musisz już pisać własnych testów, aby sprawdzić, czy 2 kolekcje są takie same.
5. Testy kombinatoryczne. Czy nie byłoby fajnie, gdybyś mógł dostarczyć dwa zestawy danych i przetestować wszystkie kombinacje danych. Jest w mbUnit.

Pierwotnie wybrałem mbUnit ze względu na jego funkcjonalność [RowTest ....] i nie znalazłem żadnego powodu, aby wrócić. Przeniosłem wszystkie moje aktywne zestawy testów z nUnit i nigdy nie oglądałem się za siebie. Od tego czasu przekonałem dwa różne zespoły programistów do korzyści.

O ile mi wiadomo, obecnie dostępne są cztery frameworki do testowania jednostkowego w .NET

• NUnit
• MbUnit
• MSTest
• xUnit

NUnit zawsze był na czele, ale luka zniknęła w ciągu ostatniego roku. Nadal wolę NUnit, zwłaszcza że dodali jakiś płynny interfejs, dzięki czemu testy są bardzo czytelne.

Jeśli dopiero zaczynasz testować jednostki, prawdopodobnie nie ma to większego znaczenia. Gdy osiągniesz maksymalną prędkość, będziesz w stanie lepiej ocenić, który system najlepiej odpowiada Twoim potrzebom.

Nie podoba mi się wbudowana platforma testowa VS, ponieważ zmusza cię to do utworzenia osobnego projektu, a nie do testowania go jako części projektu, który testujesz.

MSTest jest zasadniczo nieco przerobiony przez NUnit, z kilkoma nowymi funkcjami (takimi jak konfiguracja zestawu i porzucenie, nie tylko poziom urządzenia i poziom testowy), i brakuje niektórych najlepszych bitów (takich jak nowa składnia ograniczenia 2.4). NUnit jest bardziej dojrzały i jest obsługiwany przez innych dostawców; i oczywiście, ponieważ zawsze był darmowy (podczas gdy MSTest dostał się tylko do wersji Professional 2008, wcześniej było to o wiele droższe SKU), większość projektów ALT.NET go używa.

To powiedziawszy, jest kilka firm, które są bardzo niechętne do używania czegoś, co nie ma etykiety Microsoft, a zwłaszcza kodu OSS. Posiadanie oficjalnych ram testów MS może być motywacją, że firmy te muszą przejść testy; i bądźmy szczerzy, liczy się testowanie, a nie to, jakiego narzędzia używasz (i korzystając z powyższego kodu Tuomasa Hietanena , możesz niemalże zamienić swój szkielet testowy na wymienny).

Wraz z wydaniem w .NET 4.0 systemu Code Contracts i dostępnością sprawdzania statycznego będziesz musiał teoretycznie napisać mniej przypadków testowych, a narzędzie takie jak Pex pomoże zidentyfikować te przypadki. Odnosząc to do omawianej dyskusji, jeśli chcesz zrobić mniej z testami jednostkowymi, ponieważ twoje kontrakty obejmują twój ogon, to dlaczego nie po prostu skorzystać z wbudowanych elementów, ponieważ jest to o jedną mniejszą zależność do zarządzania. W dzisiejszych czasach chodzi mi o prostotę. :-)

Zobacz też:

• Microsoft Pex - automatyczne testowanie jednostek
• Generowanie testów jednostkowych za pomocą Pex przy użyciu Visual Studio 2010 i C # 4.0

Wolałbym używać małego szkieletu testowego MS, ale na razie trzymam się NUnit. Problemy ze stwardnieniem rozsianym są ogólnie (dla mnie)

• Udostępniony plik „testowy” (bezcelowy), który należy zachować
• Listy testów powodują konflikty z wieloma programistami / VCS
• Zły zintegrowany interfejs użytkownika - myląca konfiguracja, uciążliwy wybór testów
• Brak dobrego biegacza zewnętrznego

Ostrzeżenia - Gdybym testował witrynę aspx, zdecydowanie użyłbym MS - Gdybym rozwijał solo, również MS byłoby w porządku - Gdybym miał ograniczone umiejętności i nie mógłbym skonfigurować NUnit :)

O wiele łatwiej jest mi napisać testy i odpalić NUnitGUI lub jeden z innych interfejsów (testDriven jest zdecydowanie o wiele za drogi). Konfigurowanie debugowania za pomocą wersji wiersza poleceń jest również dość łatwe.