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 !!
Odpowiedzi:
Daok wymienił wszystkich pro projektów testowych VS2008, oto pro 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
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:
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.
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;
#endifLub 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.
Jeśli zastanawiasz się nad MSTest lub nUnit, polecam przyjrzeć się mbUnit. Moje powody są
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 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).
SetUpi TearDownatrybutów: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
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ż:
Wolałbym używać małego szkieletu testowego MS, ale na razie trzymam się NUnit. Problemy ze stwardnieniem rozsianym są ogólnie (dla mnie)
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.