Mockito - tego się jeszcze używa?

bo jak widzę tę składnie to się za głowę łapię.

Używa się. Dużo. Przeważnie bez sensu.

Olej. Mocksturbacji powiedz twarde i zdecydowane: chyba nie.

Używa się. Co ciekawe zgodze się z @jarekr000000 (zabawne, jak on tutaj się pojawił to większość czasu spedzałem na kłóceniu się z nim że mocki są fajne). Generalnie czasami się przydaje i może mieć sens, ale często jest nadmiernie wykorzystywany i sprowadza się to wszystko do testosowania mocków. Lepiej wtedy użyć stubów (czyli fejkowe implementacje zależności) lub nie testowac tylko jednej klasy mockując inne tylko wstrzyknąć rzeczywiste implementacje (tzn jeśli klasa A ma zależności od B i C to zamiast przekazac do konstruktora mocki B i C to przekazac rzeczywiste implementacje B i C)

@jarekr000000: jakie sa w takim razie alternatywy? ;)

@azalut: stuby + prawdziwe obiekty, przecież napisałem. Odnosze coraz częściej wrażenie że czas jaki poświęca się na pisanie mocków jest zbyt duży i jest to overkill... Prawda jest taka że często testowanie pojedyńczych metod czy klas nie ma sensu bo pisanie takich testów zajmuje więcej czasu i te testy tak naprawde nic nie testują (poza Mockito :D ) ;)
Oczywiście bywają przypadki że mocki moga mieć sens, ale nie zawsze :)
Pomyśl tez o tym jak często mokujesz jakieś DAO czy tam Repository, a tak walniesz sobie stuba, możesz dzielić go z innymi obiektami i masz wszystko w jednym miejscu o wiele czytelniejsze :)

Podpisuje się po powyższym.

Swego czaasu mnie zaskoczyło, że po odmockitowaniu zaczęło się robić dużo mniej kodu w testach (po prostu jak się robi tony Mockito.when - to nawet nie widać ile jest powtórzeń nonsensownych). Własne, ręczne mocki sa zaskakująco korzystne w utrzymaniu.
Przede wszystkim: wielu rzeczy nie warto mockować.
Często ludzie mają paranoiczne pojęcie unitu. Trzeba wszystko odizolować, tak żeby jak będzie bład w innych klasach to nie żeby nie wpłynął na testy.
Fajnie, fajnie... ale jak twoja klasa używa Stringa, czy HashMapy to też mockujesz implementacje Stringa ? na wypadek gdyby Oracle zmienił....
Z tego samego powodu często, nie warto mockować klas z tego samego projektu.(Mam tu zasadę jednego pokoju - jak mam zamockować coś co powstało w moim zespole, w tym samym pokoju to zastanawiam się czy faktyucznei warto).

Mocki się przydają na zewnętrzne zależności i zasoby.

Baza danych, której schemat masz pod kontrolą i jest własnością aplikacji... nie jest zależnością zewnętrzną. Traktuje ją tak samo jak HashMape - nie mockuje. Bo to nonsens. Co najwyżej testuje z wersją in memory.

A nie odniesliscie wrazenia ze Mockito jest chyba jedna z najlepiej rpzetestowanych aplikacji, bo czesto sa pisane tak wlasciwie testy Mockito :)

Mi sie bardziej Wiremock podoba. Czyli udajemy ze np. dostaejmy odpowiedz z zewnetrznego serwisu (Json, XML, whatever) i wtedy jak bedzie u nas jaksi zgrzyt w integracji to widac.

@jarekr000000: własnie te tony mocków to powód dla którego tak zacząłem wątpić w Mockito czy Mock ze Spocka. Po prostu 80% czy 90% kodu z testów to były mocki...
Mocki były bo to niby żeby ułatwić testowanie, a tak naprawde sprawiały że nie wiadomo o co chodziło w tych testach bo te testy byly totalnie nieczytelne...
Stąd moje nawrócenie :)

Wszystko jest dla ludzi. Zwykle zarzuty przeciwko mockom wynikają z tego że ktoś ich źle używa. To że ktoś robi w testach assertTrue(true) nie znaczy że asercje są złe. Po prostu trzeba wiedzieć kiedy i czego użyć i mieć ku temu powody. Jeśli masz w teście 50 linii setupu mocków, to coś jest mocno zrypane ;)
Często lepiej postawić sobie in memory DB / bazę lokalnie startowaną w trakcie testu w dockerze / serwer http który zwraca to co mu zaprogramujemy itd, ale czasem faktycznie chcemy przetestować pewną logikę w oderwaniu od jakiegoś innego serwisu i wygodnie zwyczajnie go mockować, szczególnie jak nie programujemy mu złożonego zachowania.
Nawet takie rzeczy jak Powermock mają sens, szczególnie jak musisz napisać testy dla jakiegoś starego kodu którego nie możesz ruszyć.

@Shalom: oczywiście masz racje dlatego napisałem

Oczywiście bywają przypadki że mocki moga mieć sens, ale nie zawsze

Chodzi o to żeby nie przesadzać ani w jedną ani w druga strone :) A nadmiar mockowania może wynikac ze złego designu (za duże klasy), a może być tez tak że czasami serio trudno coś przetestowac z użyciem mockow ;)

Shalom napisał(a):

Wszystko jest dla ludzi. Zwykle zarzuty przeciwko mockom wynikają z tego że ktoś ich źle używa. To że ktoś robi w testach assertTrue(true) nie znaczy że asercje są złe.

To częsty argument w obronie różnych narzędzi, frameworków. I się z nim nie zgadzam. Chyba do klasyki wszedł w formie: "It is like butchers banning knives because workers sometimes cut themselves. ". Łatwo znaleźc czego to była obrona.
Są narzędzia niebezpieczne, które niejako wymuszają problemy. Nawet dobry programista, zwykle nie jest dobry przez 8 godzin 5 dni w tygodniu, kilka miesięcy z rzędu.

Samo Mockito to:

1. genialnie zrobiona biblioteka - robi jedną rzecz i robi ją ładnie
2. ładna demonstracja siły i magii bytebuddy, dynamic proxy.
3. narzędzie ratujacek tyłek, umożliwiające wygodne testowanie kodu (designu) średnio testowalnego (, gdzie PowerMock to narzędzie umożliwiające testowanie kodu zupełnie nietestowalnego).

I niestety punkt 3 to jest problem, bo się ludzie uczą, w sposób naturalny, mockowania, że jest dobrze. Po co pracować nad testowalnością systemu? : przyjdzie mockito i wyrówna.
Jak widze system, gdzie Mockito jest stosowane raz na 20-30 testów to wiem, że pewnie jest dobrze użyte. Częściej jednak spotykam totalną mockstubację - prawie każdy test to Mockito.when, Mockito.when - aż do porzygu.
Dlatego, chwilowo raczej mockito zwalczam, puty przechył jest w tą stronę, może to sie kiedyś wyrówna.

Co do całości postu @Shalom to w zasadzie, nie mam się z czym kłócić. Prawdę pisze. Tym niemniej ten argument o dobrym i złym użyciu narzędzi, jest średni. W ten sposób można wiele dziwnych rzeczy wybronić. Od dawna biorę pod uwagę to, jak sobie radzi przeciętny Joe i co z tego wychodzi.

Nie rozumiem tej niechęci do Mockito. Jest to bardzo fajne narzędzie do testowania. Wiadomomo, że nie można popadać w skrajność i robić absurdów typu mockowanie Stringa i wszystkiego, co się da, ale mockując interfejs używany w jakiejś testowanej klasie możemy bardzo fajnie obtestować różne przypadki użycia kodu z tejże klasy. Można oczywiście zrobić to "na pałę" robiąc różne sztuczne implementacje tych inferfejsów dla potrzeb testów, ale Mockito jest chyba lepszym rozwiązaniem tego problemu.

To w takim razie weźmy metode1 z klasy klasa1, która wywołuje inną metodę2 z klasy2 (zależność klasy1) i robi coś na podstawie tego wyniku

Wiemy, żę metoda2 może wrócić rozne wyniki i nasza metoda1 sie możę zachować różnie
Chcemy takie przypadki pokryć, powiedzmy ze jest ich 4

mam zrobić osobne 4 stuby klasy2? czy jest jakiś magiczny stubber o którym nie wiem

A taki przypadek:
Mamy 5 klas w jednym pakiecie. Jedna klasa jest publiczna i wystawia jedną publiczną metodę. Reszta klas jest pakietowa i są to jakieś klasy które są wykorzystywane przez tą publiczną.
Powiedzmy że jest to walidacja jakiegoś obiektu i jest sprawdzane wiele warunków w tych wszystkich klasach.
Czy jest sens testować każdą klasę z osobna (mockowac i izolować) czy tylko wejście z zewnątrz (jedna publiczna metoda, tworzone są prawdziwe instancje obiektów) i zachowanie takiego modułu (tudzież walidacji) skoro tylko pełna walidacja ma sens z biznesowego punktu widzenia?

Nie ma ogólnej odpowiedzi. Jeśli w tych "wewnętrznych" klasach jest dużo złożonej logiki, którą cieżko dobrze przetestować przez ten jeden entry point (choćby dlatego że masz wykładniczo dużo ścieżek), to wtedy jest sens testować pewne rzeczy w izolacji.

okej to załóżmy że klasa2 ma 5 zależności, mam to ciągnąć przez cały system? ja chce przetestować zachowanie jednej metod

Dokładnie, mockito pozwala to prosto przetestować. I to dokładnie nazywam kiepskim / średnio testowalnym designem, który mockito przykrywa. (przestaje boleć).

Boli Cie ząb wiec bierzesz tabletkę przeciwbólową, na krótką mete to oczywiście jest sposób.