Jakiś czas temu w pracy mieliśmy dużą dyskusję na temat sposobu tworzenia mocków. Gorącym tematem okazał się poziom restrykcyjności mocków. Ustaliliśmy w końcu, że będziemy używać loose, jednak ja nie do końca poczułem się przekonany (wcześniej przez kilka lat używałem strict, może to dlatego). W skrócie: mock strict rzuci wyjątek przy każdym wywołaniu nieskonfigurowanej lub niepoprawnie skonfigurowanej metody, mock loose w takim przypadku zwróci null. W praktyce przekłada się to na to, że
- podejście strict - jak sama nazwa wskazuje - jest dużo bardziej restrykcyjne, bo musi być dokładnie zasetupowana każda zależność (z dokładnością do kruczków typu
It.IsAny<T>
). To oznacza, że pisząc jeden test przy okazji sprawdzamy więcej rzeczy, niż by wynikało z samego testu. To często pozwala wykryć własne błędy, acz zbyt dalekie pójście w tym kierunku, czyli pisanie minimum testów, może oznaczać przegapienie pewnych istotnych ścieżek wykonania. Jest to też trochę upierdliwe przy refactoringu albo modyfikacji istniejących funkcjonalności, bo często trzeba poprawiać dziesiątki testów sprawdzających kompletnie co innego niż to,co zmieniliśmy w testowanej metodzie. Ale skoro zmieniliśmy coś w działaniu metody, no to na chłopski rozum jej testy powinny się wywalić. To się nazywa testowanie implementacji. - podejście loose umożliwia setup tylko testowanej ścieżki wykonania - skonfigurowane są tylko te metody, które są niezbędne do poprawnego wykonania testu. Jeśli dodamy nową funkcjonalność do testowanej metody (np. weryfikacja uprawnień użytkownika), to istnieje duża szansa, że test się nie wywali, o ile tylko nie rozwalimy ścieżki prowadzącej do sprawdzenia testowanej funkcjonalności. To podejście też jest fajne, bo przy modyfikowaniu istniejących rzeczy wywali się nam mało testów albo wręcz żaden, ale wywołuje to we mnie pewną nieufność ;-) Przy refactoringu jest więcej roboty, bo powstaje więcej testów (strict może testować wiele ścieżek, loose tylko jedną, więc musi być więcej testów w tym drugim przypadku). Więcej testów niekoniecznie jest wadą, bo są one bardziej szczegółowe, ale też łatwiej coś przegapić. To podejście nazywa się testami funkcjonalności.
Po tym długim wstępie pytanie - którą drogą idziecie w waszych projektach i dlaczego?