Jakie są kluczowe czynniki przy wyborze Mocking Framework?

Chcę zacząć od obiektów w moich testach jednostkowych. Wygląda na to, że istnieje mnóstwo dobrych szyderczych ram.

1. Czy różne ramy mają różnych docelowych odbiorców?
2. Jakie czynniki należy wziąć pod uwagę, wybierając ramy odpowiednie dla mojej sytuacji?

Czy różne ramy mają różnych docelowych odbiorców?

Tak. Niektóre frameworki, takie jak Microsoft Moles , TypeMock Isolator i JustMock , pozwalają na kpowanie z wszystkiego. Te narzędzia próbne są na ogół lepsze dla programistów, którzy chcą ich używać w istniejącym starszym kodzie, ponieważ może nie być możliwe przeformułowanie takiego projektu na bardziej testowalny. *

Tradycyjnie, testowalne projekty oznaczają, że podstawa kodu musi swobodnie korzystać z interfejsów, klas abstrakcyjnych, metod wirtualnych, niezamkniętych klas itp. Dlatego tradycyjne frameworki takie jak Moq i RhinoMocks działają dobrze z kodem opracowanym przy użyciu Test Driven Development, Dependency Injection i inne takie pojęcia. Nawiasem mówiąc, zdecydowanie zaleciłbym użycie Dependency Injection, ponieważ zyskujesz znacznie więcej niż tylko testowalny kod, ale także łatwiejszy do utrzymania kod.

Jakie czynniki należy wziąć pod uwagę, wybierając ramy odpowiednie dla mojej sytuacji?

• Działalność deweloperska. Narzędzia takie jak Moq i RhinoMocks są bardzo aktywne i popularne, a zatem są aktualne.
• Open Source vs. Commercial . Rozważ różne zalety i wady typowe dla tego porównania. Koszt, wsparcie itp.
• Dojrzałość. Jak nowe jest narzędzie. Czy jest w wersji beta (jak Microsoft Moles), czy ma kilka stabilnych wydań? Na przykład podoba mi się Moles dla starszego kodu, ale jest kilka błędów, które należy w nim usunąć i będzie trzeba czekać, aż zostaną zaadresowane (następne wydanie, listopad 2011).
• Dokumentacja. Istnieje kilka książek i blogów, które obejmują testy jednostkowe, kpiny, auto-kpiny itp. Dodatkowo, jak dobra jest własna dokumentacja narzędzia?
• Składnia . Każde narzędzie ma swój własny sposób na powiedzenie tego samego. Sprawdź, który z nich jest dla Ciebie lepszy.
• Prędkość . Narzędzia korzystające z profilowania CLR (TypeMock, Moles, JustMock) mogą być znacznie wolniejsze niż tradycyjne (Moq, RhinoMocks). Ta kara prędkości może być problemem, ponieważ gromadzisz wiele testów jednostkowych. Zasadą jest, że jeśli test trwa dłużej niż 1/10 sekundy, jest zbyt wolny.
• Wsparcie społeczności . Czy inni programiści piszą inne narzędzia, które rozszerzają (lub działają w komplement) do narzędzia kpiącego? Istnieje projekt Moq.Contrib , który dodaje Moq funkcję Auto-mocking (która pomaga przyspieszyć czas pisania testów). Jeszcze lepiej, jest AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, który pozwala również na automatyczne mocking oraz tworzenie anonimowych zmiennych.

^{* Zobacz Efektywna praca ze starszym kodem , aby dowiedzieć się, jak powoli refaktoryzować kod bez testowania kodu, którego można używać z tradycyjnymi narzędziami testującymi (i kpiącymi).}

Poradnik Moq ma przekrój w tle, filozofii i prawa kontrowersje na początku omawiającej ten w odniesieniu do kilku konkretnych narzędzi: TypeMock izolatora RhinoMocks i Min. Jest napisany, aby wyjaśnić Moq, więc jest oczywiście nieco wypaczony, ale uznałem, że jest to dla mnie bardzo pomocne, gdy próbuję zrozumieć niektóre różnice w kpinach.

Znalazłem również odpowiedzi na ten wątek SO w C # Mocking Frameworks . Większość odnosi się tylko do jednego z Mocking Framework, który użytkownik naprawdę uważa za użyteczny, ale istnieje odpowiedź od HaraldV , która omawia symulacje oparte na proxy i symulacje oparte na profilowaniu.

Udało mi się również znaleźć tabelę porównawczą online. Pamiętaj, że pochodzi z 2009 roku, więc nie jestem pewien, czy jest aktualny; jest co najmniej jeden komentarz stwierdzający, że informacje o TypeMock i wywołaniach zwrotnych są nieaktualne, ale wykres może być dobry do zgłaszania problemów do rozważenia, nawet jeśli będziesz musiał zrobić pracę nóg, aby zobaczyć, jaki jest obecny stan: RhinoMocks, Moq, NMock, i tabela porównawcza TypeMock

W Google Code jest projekt z przypadkami testowymi w wielu frameworkach, które ułatwiają porównywanie kodów: makiety-frameworki

1. Łatwość użycia. Niektóre frameworki mają bardziej zaawansowane idiomy użycia. Na przykład MOQ pozwala na użycie lambd do kodowania oczekiwań. Niektóre starsze biblioteki nie obsługują tego.
2. Prędkość. Każdy test jednostkowy powinien być szybki, aby cała biblioteka nie zajmowała godzin. Niektóre frameworki mają generowane statycznie makiety, co jest szybkie. Inne frameworki dynamicznie generują kod w czasie wykonywania, który jest wolniejszy.
3. Wsparcie. Potrzebujesz frameworka, który jest aktywnie obsługiwany za pomocą poprawek i aktualizowany w celu obsługi nowych wersji platformy .NET w miarę ich wydawania.
4. Moc. Większość kpiących struktur, które badałem, jest mniej więcej taka sama pod względem mocy. Jest jeden znaczący wyjątek. Microsoft Moles pozwala na kpowanie z „nie-wirtualnych / statycznych metod w typach zapieczętowanych”. Jest to coś, czego, według mojej wiedzy, nie wspierają żadne inne szydercze ramy.

W moim zespole wybraliśmy Microsoft Moles . Wygrywa znacząco na # 2, # 3 i # 4, chociaż jest mniej idiomatyczny niż większość alternatyw i jest na niskim poziomie na # 1.