Pewnie pisałem już to, ale powtórzę.
Dlaczego nie kocham Mockito
a) bo wcale wiele nie daje - bez mockito jestem w stanie zrobić mocki w mniej więcej tyle samo linijek kodu (chociaż niektórzy będą twierdzić, że nieprawda - patrza punkt 2), jesli niewiele daje to po co zaśmiecać kod kolejnym narzędziem
b) Mockito oczywiście wiele daje jeśli korzystamy z mockito.verify, wtedy żeby odtworzyć tąką funkcjonalność trzeba by się namęczyć, ale akurat uważam testowanie verify za antywzorzec.
Co mnie obchodzi czy funkcja w środku wywołała repozytorium, jesli dała dobry wynik? Jak ktoś napisze funckcę zwracającą poprawne raporty z bazy bez odnoszenia się do tej bazy to super, mi pasuje.
Nienawidze betonowania implementacji jaka zachodzi przy używaniu verify (i ogólnie london tdd) .Są wyjątki- typowym wyjątkiem jest funkcja sendMail - fire and forget, chociaż na upartego można postawić serwer pocztowy i sprawdzać czy przysżło w teście...
c) może problem wynika też z tego ,że ludzie uważaja za obowiązek zamockowania w tzw. unit teście wszystkiego co nie jest w unicie. Ja nie widzę w tym podejściu żadnego sensu. I problemu nie mam, bo nie piszę unit testów - piszę po prostu testy.
d) Jak się rozrośnie popularność Mockito w projekcie to łatwo przeoczyć, że pewne testy zaczynają testować li tylko Mockito. Oczywiście prawdziwi, porządni i uważni programiści tego nie robią.
Ale puty takich programistów nie ma i trzeba się męczyć z ludźmi to niestety jest problem. Oczywiście można wprowadzać kolejne narzędzia - typu testy mutacyjne do łapania tego... tylko nie wiem czy to nie jest równia pochyła (nigdy nie wprowadziłem testów mutacyjnych dalej niż jako krótki i męczący eksperyment). Na review takie rzeczy nie wychodzą. Po prostu nie. Ileś razy gapiłem się w test i zastanawiałem się czy on w ogóle coś testuje (i w końcu musiałem sprawdzić) - długo to trwa. Tu na forum ileś razy ludzie takie kwiatki jako testy podesłali.
Mockito / moków ogólnie używasz jak masz zewnętrzną zależność nad którą nie panujesz (np. sendMail).
Coś co jest współdzielone lub nie masz możliwości przywrócenia stanu tego czegoś do stanu inicjalnego sprzed testu.
Czasem udaje się zrobić testy działające na swoim podzakresie danych w bazie współdzielonej, ale to ryzykowne zagranie.
Lepsza jest baza lokalna, a najlepsza in-memory.
Kilka miesięcy temu pod wpływem nienawiści do Mockito (mockowane repozytoria, nie polecam...) napisałem to: https://github.com/Potat0x/nomock Sam nie miałem okazji tego użyć i nie wiem czy w praktyce komuś się przyda ten wynalazek, ale zostawiam ;)
A nie lepiej w ogóle nie pisać testów? Myślę, że to was pogodzi. Wszyscy będą zadowoleni.
@Meini ma ogólnie rację, gdyby to był jakiś nowoczesny język...
Ale pytanie dotyczyło javy.
https://www.hacklewayne.com/types-and-tests-javascript-10-idris-0
Testing is a poor substitute for proof.
https://bartoszmilewski.com/2014/11/24/types-and-functions/
Ja używam mockito, żeby mi komary do domu nie wlatywały
Polecam super artykuł jak zrobić testy integracyjne z Mockito:
https://reflectoring.io/spring-boot-web-controller-test/
An integration test with Spring fires up a Spring application context that contains all the beans we need.
xd
Najpierw piszemy spagetti kod, czym bardzie skomplikowany i z większą ilością zależności tym lepiej.
Musisz kod napisać tak żeby nie dało się napisać normalnego unit testu. Pamiętaj normalne unit testy są dla juniorów, a Ty chyba nie chcesz być juniorem?
Musi wyglądać skomplikowanie nie piszemy przecież banałów. Jak już masz spagetti kod to mockujesz 200 zależności i wtedy jesteś seniorem