Temat: Nunit

Jakie są wasze opinie na narzędzia o nazwie Nunit?
Muszę wdrożyć do nowych projektów testy jednostkowe, mój wybór jak na razie padł na Nunit.
Mam trochę ograniczony wybór gdyż będę głównie pracował niestety w Visual Studio 2005:(
Więc MSUnit (o ile mi wiadomo) odpadają, a szkoda bo zazwyczaj jestem chętny skłaniać się do rozwiązać autora środowiska w którym pracuję.

Myślę do nunit dodać tylko snippet - y kodu - szkielety testów nunit.
Same testy odpalać z gui dołączonego do nunit.
Ewentualnie myślałem nad jakimś systemem ciągłej integracji(CruiseControl.NET, Hudson) - odpalanie testów za pomącą nAnt.

Jakie są wasze doświadczenia / przemyślenia na temat testów jednostkowych?
A i jeszcze parę pytań zupełnie zielonego(w temacie ) pana:
Czy klasy testów kompilować do oddzielnych dll?(znalazłem opinie aby umieszczać w tej samej co kod właściwy programu, co wydaje mi się raczej złą praktyką)
Tak w praktyce czy warto wcześniej pisać testy potem kod (TDD)?
Obejdzie się na początku bez mock object(czy coś takiego)?

Z góry dziękuję za przemyślenia.

Temat: Nunit

Mocki to chyba głównie do BDD niż do TDD.

Zresztą wydaje mi się, że ważniejsze od wyboru testów jednostkowych jest ich dobre napisanie. Jeśli test nie będzie według schematu Arrange, Act, Assert to tak naprawdę nie będzie wiadomo co testuje. To trzeba sobie wkuć do głowy i wyrobić nawyk.

Testów w ogóle bym nie włączał do kodu aplikacji.

Temat: Nunit

Zgadzam sie z Boryslawem. Osobiscie w pracy uzywam NUnit z VS2010 i jest wporzadku. Nigdy nie mielismy z nim problemu jesli chodzi o kompatybilnosc z VS. Od zawsze kompilujemy osobna DLL-ke dla testow i nigdy nie myslelismy o umieszczeniu kodow w testach. Moja osobista opinia jest taka, ze po umieszczeniu testow w kodzie, aplikacja sie rozrosnie (szczegolnie przy duzych projektach) i klienici zamiast sciagac faktyczna DLL-ke czy EXE-ka podczas update-ow beda dodatkowo sciagac twoje testy, a po co? Testy sa dla Ciebie.

U nas w firmie wyglada to tak, ze mamy kilka projektow w naszej aplikacji a jednym z nich jest "TEST project", ktory jest odpowiedzialny za wszystkie testy w aplikacji. To rozwiazanie stosujemy juz od ponad roku i wydaje sie byc bardzo dobre i elastyczne.

Na poczatek, przy prostych testach samych metod (bez przekazywania obiektow do nich) spokojnie sie obejdziesz bez Mock-ow. Zasada przy testowaniu jakiegos obiektu/metody jest taka, ze wszystko co sie znajduje wokol obiektu/metody powinno byc zMock-owane. Dlatego przy testach prostych metod spokojnie obejdziesz sie bez Mockow. Czasami, jesli test tego wymaga, mozna przekazac faktycznie utworzone obiekty i tez mozna obejsc sie bez Mock-a.

Jedyne na co zwrocilbym uwage, to przywiazanie programist-y/-ow do nawyku pisania testow przed pisaniem kodu. U nas nawet po roku pisania testow nadal sie z tym zmagamy ;). Druga rzecz to pisanie naprawde dobrych testow, czyli testow, ktore sprawdzaja faktycznie to co chcesz przetestowac i tylko to, nic poza tym.

Nie chce zasmiecac watku, wiec pozwole sie wypowiedziec innym :)

Pozdrawiam i powodzenia,
Mirek

Temat: Nunit

zazwyczaj (choc nie zawsze) schemat jest taki:
1. dodajemy nowy projekt z referencja do NUnit + referencje do "softu" testowanego
2. projekt ten zazwyczaj jest kompilowany do dll
3. testy jak juz wyzej Boryslaw napisal - koncza sie assertami, skierowanymi na konkretne elementy - im bardziej szczegolowe, tym lepiej. --> dla jednego elementu czesto wystepuje N scenariuszy, co zdecydowanie poprawia w efekcie jakosc stworzonego rozwiazania.
3a. Jednostkowe - jak sama nazwa wskazuje powinny w mojej opinii testowac mozliwie jak najmniejszy fragment funkcjonalnosci
4. warto przynajmniej spojrzec w CodeCoverage i dowiedziec sie, ile tak na prawde kodu przetestowalismy
[..]
100. W niektorych projektach (lub zdecydowanej jej wiekszosci) warto zaczac wlasnie od pisania testow i pobawic sie chocby poczatkowo dla zabawy w TDD. Sporo ulatwia to zycie, jesli wiemy co chcemy osiagnac, a nie najpierw piszemy a pozniej dziwimy sie co z tego wyszlo ;)

101. NUnit podobnie jak JUnit sa pewnymi standardami, dobrze zdokumentowanymi, z dobrym wsparciem, z duzymi mozliwosciami i wieloma praktykami, ktorzy zeby na tym zjedli przyslowiowo - stad osobiscie polecam ich stosowanie w testach jednostkowychPiotr Jędrkowiak edytował(a) ten post dnia 29.11.11 o godzinie 07:20

Temat: Nunit

Marcin,

Polecam kombinację nUnit + testdriven (http://www.testdriven.net/) OR/AND ReSharper (http://www.jetbrains.com/resharper/)

Tutaj znajdziesz filmik co się z czym je http://www.youtube.com/watch?v=1TPZetHaZ-A

Temat: Nunit

Są mocki i stuby - warto o tym poczytać. Dla zielonych Pan Anisierowicz (http://maciejanisierowicz.com) ostatnio zrobił ciekawy cykl o testach wraz z narzędziami itp.
Panie Piotrze narzędzia takie jak nCrover lub nCrunch (ciekawe bo się z Visualem spina i na bieżąco w tle wykonuje testy i pokazuje ich wyniki dla aktualnie pisanego kodu) niestety pokazują tylko czy dana lnijka jest wykonywana w testach, a czy rzeczywiście sprawdzana to już niekoniecznie...

Temat: Nunit

Akurat jest piątek :) więc radzę kupić sobie książkę na weekend: http://www.manning.com/osherove/ i od poniedziałku Twoja wiedza na temat testowania będzie w stopniu zupełnie wystarczającym do dobrej pracy.

Nie trzeba również (IMVHO) kupować narzędzi - http://www.gallio.org/ może z powodzeniem służyć jak "uruchamiacz" testów, zwłaszcza jak masz dwa monitory.