Wybór mock-object framework

Przed rozpoczęciem wykorzystywania mocków w swoim projekcie musimy zdecydować się z jakiego wspomagacza skorzystamy. Wiemy jedno: nie chcemy tworzyć mocków ręcznie (jak zostało to przedstawione tutaj). Zobaczmy więc co nam, programistom .NET, oferuje w tym zakresie wszechposiadający, uzależniający i niczym tlen niezastąpiony INTERNET.

Nie jest moim zamierzeniem dokładna prezentacja i porównanie dostępnych rozwiązań – rzucę raczej okiem na kilka możliwych ścieżek.

Przed dalszą lekturą można na chwilę cofnąć się do jednego z poprzednich postów (Mock Objects – pierwszy test krok po kroku), gdzie zetknęliśmy się już z testem, który spełnia (przynajmniej moje) oczekiwania.

NMock2

Na pierwszy ogień pójdzie NMock2. Po ściągnięciu biblioteki i dodaniu referencji nachodzi czas na napisanie testu. Będzie on robił to samo co ten, z którym mieliśmy już do czynienia – weryfikował wywołanie metody z odpowiednimi parametrami. Po zerknięciu do dokumentacji on-line przystępujemy do pracy i w efekcie otrzymujemy test:

Hmmm… Z tą biblioteką miałem do czynienia ponad 2 lata temu. To właśnie ona była moim typem gdy stawiałem pierwsze kroki w świecie testów jednostkowych i mocków. Widzę niestety, że ohydny sposób pracy z mockami, który odrzucił mnie wówczas, nie uległ zmianie. Nadal korzysta się ze stringów reprezentujących nazwy metod!! Najprostszy refactoring – zmiana nazwy metody – rozwala nasze testy (fakt, że Resharper umie odnaleźć takie miejsca, nie ma żadnego znaczenia)! Szczerze mówiąc nie ma nawet sensu zaglądać głębiej, takie coś to bezwzględna DYSKWALIFIKACJA! Powstały inicjatywy naprawienia tego stanu rzeczy (jak ta tutaj), ale chyba nie po to ściągamy bibliotekę mającą wspomóc naszą pracę, aby się w niej grzebać.
Jako uzupełnienie wspomnę jeszcze, że w jednym z ostatnich numerów MSDN Magazine ukazał się artykuł (“Using Mocks And Tests To Design Role-Based Objects”), w którym autor korzysta z mocków właśnie w ten sposób. I nie wspomina nawet, że istnieją LEPSZE alternatywy. Czegoś takiego w MSDN Magazine się nie spodziewałem.

TypeMock

W tym przypadku lektura strony projektu spowodowała, że nawet nie ściągnąłem żadnego pliku. Z dwóch powodów:

• cena (cennik): może 89 euro nie jest wielkim wydatkiem za licencję personal, ale jednak… mając do wyboru darmowe alternatywy rozsądnym rozwiązaniem jest uprzednie dokładne przyjrzenie się ich możliwościom
• kwestia ważniejsza: sposób działania i wpływ na projekt; używając TypeMock wykorzystujemy tylko JEDNĄ z DWÓCH głównych zalet testów jednostkowych, i to wcale nie najważniejszą (oczywiście moim zdaniem, o czym pisałem już wcześniej); głównym “killer feature” tego projektu jest możliwość zamockowania i przetestowania WSZYSTKIEGO, niezależnie od architektury systemu; dzieje się tak, ponieważ twórcy poszli w kierunku Aspect-Oriented Programming i po prostu bezwzględnie przechwytują wywołania odpowiednich metod – ot i cała magia; cytaty ze strony: “Other mocking frameworks can only work when a special and complex pattern called Inversion of Control is used” oraz “If you are looking for a robust solution that will give you the freedom to design your code without using Inversion of Control patterns, you should use Typemock Isolator.” mówią wszystko… jeśli nie obchodzi cię JAK program jest napisany, a potrzebujesz jedynie weryfikacji jego działania (co z pewnością w pewnych scenariuszach zawierających w sobie rozwijanie już istniejących wielkich systemów pozbawionych testów czy testowanie pod Sharepointem  – jest przydatne) to może być to produkt dla ciebie; ja jednak preferowałbym refactoring kodu do testowalnej w normalny sposób postaci, dzięki czemu w efekcie oprócz testów uzyskalibyśmy również system o wiele prostszy w zrozumieniu i utrzymaniu

Moq

Przyznaję się bez bicia, że o tym rozwiązaniu słyszałem same dobre rzeczy, jednak nigdy z niego korzystałem. Zapoznałem się z nim jedynie na potrzeby niniejszego posta, ponieważ jest to gracz zdobywający na rynku mocków coraz większą popularność i brzydko byłoby go pominąć.
Zaczniemy więc jak zwykle od zajrzenia na stronę projektu. Z pomocą przykładów zaprezentowanych w dziale Quickstart skonstruujemy nasz test:

I cóż… Podoba mi się! Dokładnie w taki sposób chcę korzystać z mocków, czysto łatwo i przyjemnie. Do tego strona zawiera przykłady przydatne na co dzień, pomimo tego że nie są najbanalniejszymi scenariuszami pod słońcem. Brawo, polecam!

Rhino Mocks

O tym projekcie pisałem już wcześniej, z niego korzystam i podoba mi się. Pobrać można go stąd. Dla formalności obrazek z testem napisanym przy użyciu tego właśnie rozwiązania:

Można łatwo zauważyć, że nie różni się on prawie niczym od Moq. Zatem jak łatwo się domyślić: polecam również! Rhino Mocks używam już od dawna, i planuję w tym minicyklu przybliżyć kilka dość ciekawych rozwiązań problemów, na jakie możemy się natknąć podczas pracy z tą właśnie biblioteką. Żeby jednak wszystko było jasne:

Moq vs Rhino Mocks – winner takes it all

Tak jak napisałem, pozostałe posty z tej serii opierać się będą na Rhino Mocks. Dlaczego? Głównie dlatego że dość dobrze znam ten framework oraz że takie było zamierzenie, gdy planowałem pisanie postów na ten temat:). Przyznać jednak muszę, że twórcy Moq mi zaimponowali i Z PEWNOŚCIĄ w jednym z następnych projektów zastąpię Rhino przez Moq. Choćby po to, żeby zobaczyć “jak to jest”. Oba rozwiązania pozwalają na zastosowanie schematu AAA (Arrange-Act-Assert, ale o tym w niedalekiej przyszłości), przy czym Moq sprawia wrażenie, jakby powstał dokładnie po to. Za Rhino z kolei, jakkolwiek debilnie by to nie zabrzmiało, “ciągnie się odór przeszłości”:). AAA zostało “doczepione” do Rhino za pomocą extension methods w wersji 3.5, co może u początkujących użytkowników wywołać niemałą konfuzję. Jak pisać test, skoro mam do wyboru dwa (a nawet trzy!) sposoby do osiągnięcia tego samego celu? I między innymi tym zajmiemy się wkrótce.

Co o tym sądzicie? Czy ktoś ma ciekawe doświadczenia w pracy z tymi bibliotekami? A może istnieje jeszcze jakaś warta uwagi, którą pominąłem w tej krótkiej wyliczance? Wszelkie opinie oczywiście więcej niż pożądane.