Przeczytałem wiele na temat dostępnych frameworków testowania jednostek .NET. Nie jest dla mnie jasne, jakie są kluczowe cechy, które wyróżniają dostępne struktury. Jakie są niezbędne funkcje, których szukasz podczas oceniania ram testowania jednostkowego?Moduły testowania jednostek - Jakie są kluczowe funkcje
Zgadzam się, że wszystkie są dość podobne, jeśli chodzi o twierdzenia i inne podstawowe cechy. Tam, gdzie zaczynają się różnić, znajdują się bardziej zaawansowane opcje, takie jak skrypty, narzędzia do budowania, automatyczna integracja itd.
Jeśli zamierzasz przeprowadzić wysoce zautomatyzowany proces kompilacji za pomocą czegoś w rodzaju CruiseControl.NET z wieloma niestandardowymi kompilacjami opcje i niestandardowe scritowanie prawdopodobnie użyłbym NUnit. Istnieje znacznie więcej haczyków do uruchamiania innych akcji w oparciu o wyniki testu.
Jeśli dopiero zaczynasz testowanie jednostek i planujesz tylko podstawowe testy integracyjne, pozostanę przy MStest ze względu na ścisłą integrację z Visual Studio 2008. (NUnit ma opcje integracji z IDE, ale lepsze koszty narzędzi . pieniędzy)
Oto trochę porównanie tabela:
| NUnit | MStest
---------------------------------------------------------------------------------
Asserts | missing some collection asserts | missing some numeric/date asserts
---------------------------------------------------------------------------------
Speed | test run fast, faster setup on | w/ VS 2008 no setup necessary on
| servers and the like | the client, test run fairly fast.
---------------------------------------------------------------------------------
Options | a lot of 3rd party add-ons and | some 3rd party tools
| other tools |
---------------------------------------------------------------------------------
CC.NET | good integration, lots of tools | newer versions of CC.NET support
| and options | MS test out of the box, not as
| | many add on tools
---------------------------------------------------------------------------------
Wszystkie robią bardzo podobnie, a jeśli nie, mają punkty rozszerzenia, co oznacza, że możesz osiągnąć to samo. I w tym sensie możesz je oceniać na podstawie tych samych kryteriów, których używasz przy wyborze dowolnego frameworka (np. Popularność (NUnit), MS-Certiffied (MS-Test) itp.)
Jeśli jednak potrzebujesz porady dotyczącej wyboru jeden, proponuję przeczytać na stronie XUnit "why did we build xunit", która wskazuje pewne problemy związane z jednostkowymi frameworkami testowymi.
Jeśli chcesz zobaczyć pewne podobieństwa między wszystkimi frameworkami, możesz zobaczyć z tabeli here, wszystkie mają wiele podobnych funkcji, po prostu różne słowa dla rzeczy.
Oczywiście wybór szkieletu BDD to inny czajnik.
Oto kilka rzeczy, szukam
Assert.Throws? Czy dowody są w stanie dokonywać porównań numerycznych z określoną tolerancją?Rzecz, której szukam, to obsługa zestawów narzędzi, a moim priorytetem jest wsparcie ciągłej integracji. Najważniejszą częścią testów jednostkowych (przynajmniej dla mnie, nie będąc wielkim fanem TDD) jest podłączenie ich do mojego serwera budowania CI.
Z tego powodu faworyzuję nUnit, ponieważ w CruiseControl dostępne są gotowe zadania konstrukcyjne, które są moim ulubionym serwerem kompilacji. Nie znaczy to, że nie można podłączyć żadnych innych frameworków testowych do CC, nUnit po prostu jest łatwy do użycia.
Jeśli chodzi o dostępne funkcje, MSTest ma kilka naprawdę fajnych dodatków po uruchomieniu go z fantastycznie wycenionym Visual Studio Team System z TFS na zapleczu.
Powiedziawszy to wszystko, tak naprawdę nie ma tak dużej różnicy w funkcjonalności poszczególnych frameworków testowych (mam doświadczenie z xUnit, nUnit i MSTest) - wszystkie pozwalają na zdefiniowanie testów jednostkowych i raportują jak Minęło mimochodem, a ile nie. Wszystkie mają jakiś GUI i można je zintegrować z serwerami build.
Jedną rzeczą, że tęsknię w prawie każdym ramach testowania jest jednolite twierdzenia, przez co rozumiem, że testy powinny wyglądać th To samo, niezależnie od tego, co twierdzę. Niezależnie od tego, czy wykonuję twierdzenia oparte na wartości na wartościach, asercje oparte na zachowaniu na próbce, czy też twierdzę, że należy rzucić wyjątek.
Mam zamiar użyć Rubiego jako przykładu, ale dotyczy to dowolnego środowiska. (A tak przy okazji, nie jesteś ograniczony do C# ram do testowania aplikacji .NET, można użyć żadnego języka .NET, które Ruby jest oczywiście jeden, podobnie jak Python, Schemat, F #, ...)
To jest test/unit (port wczesnej wersji JUnit) z Mocha do kpiny.
def test_state
assert_equal 2, 1+1
end
def test_exception
assert_raises(NoMethodError) { [].not_a_method }
end
def test_behavior
o = Object.new
o.expects(:ping).with(:pong)
o.ping(:pong)
end
Zobacz, jak wszystkie asercje wyglądają inaczej i znajdują się w innym miejscu, a rzeczywisty kod testowy znajduje się również w trzech różnych miejscach.
A to jest Oczekiwania, które AFAIK jest jedyną strukturą, która dobrze to robi. (Rzeczywiście, został stworzony specjalnie w celu jednolitych twierdzeń.) Niestety, nie jest już utrzymywany ani wspierany, ponieważ autor nie wykonuje już żadnej pracy z Rubinem.
expect 2 do
1+1
end
expect NoMethodError do
[].not_a_method
end
expect Object.new.to.receive(:ping).with(:pong) do |o|
o.ping(:pong)
end
Należy pamiętać, że asercje zawsze wyglądają tak samo, a zarówno twierdzenia, jak i kod testowy są zawsze w tym samym miejscu.
Nowsze frameworki, takie jak xUnit.Net i Mockito, zdecydowanie się zbliżają.
Testy jednostek programistycznych (zauważ, że jestem nie mówiąc o testach akceptacyjnych skierowanych do klienta!) Są jak kod produkcyjny: powinny być napisane w taki sposób, aby było oczywiste, co robią. Jest to nawet ważniejsze dla testów niż dla kodu produkcyjnego, ponieważ dzięki kodowi produkcyjnemu masz testy, aby powiedzieć, czy kod działa, czy nie, z testami, wszystko, co masz, czyta je i sprawdzasz, czy mają one sens, czy nie. nie.
Dlatego testy jednostek skierowane na programistę nie powinny wymagać komentarzy. I testowe nazwy są komentarzami, zatem twoja struktura nie powinna zmuszać cię do wymieniania twoich testów.
Oto przykład (w RSpec, co oczywiście może być również używany na .NET, to czas):
describe Array do
it 'should be empty' do
Array.new.should be_empty
end
end
To jest po prostu głupie. Dowolny programista, który potrzebuje nazwy testowej, aby zrozumieć, co robi ten test, powinien poważnie zastanowić się nad wyborem swojej kariery. Mają również zastosowanie te same problemy z komentarzami: co jeśli ktoś zmieni test, ale zapomni zmienić nazwę? Teraz nazwa jest nie tylko bezużyteczna, ale także myląca!Jest to o wiele lepiej:
describe Array do
it do
Array.new.should be_empty
end
end
RSpec ma inną fajną sztuczkę w rękawie: zostanie ona automatycznie utworzyć instancję klasy testowanej dla ciebie, tak, że nie masz do powiedzenia ClassUnderTest.new.should znowu i znowu, można po prostu powiedzieć should:
describe Array do
it { should be_empty }
end
A tak przy okazji, jak deweloper może dowiedzieć się, co to jest testowanie, dzięki czemu można rspec. To co to wypluwa we wszystkich trzech przypadkach, jeśli poprosić go o podsumowanie klienta czytelny w TestSuite:
Array
- should be empty
Twój stół zdobywa ważny wiersz (w leas dla mnie) - Integracja z TFS – PiRX