Mokito i dobre praktyki

Tak .. wiem .. tytuł zawiera sprzeczność.

No ale trafiłem do projektu gdzie adnotacji, użycia mokito, i ilości zależności w klasach jest więcej niż przewiduje ustawa. Generalnie co się da to jest wpychane do aspektów. Dodatkowo sonar każe pisac testy do każdej klasy więc siłą rzeczy są te moki wszędzie, a dodatkowo jest betonowana implementacja przez verify.

Dzisiaj złapałem się na tym, że 1h rozkminiałem co w zasadzie testować, którą warstwę mokować, a na koncu doszedłem do tego, że nie ma wiremocka i w sumie to beany z uderzeniem do innych api są mockbeanowane :-]

Jak sobie radzicie w takich środowiskach? Sugerować architektowi testowanie raczej behawioralne z użyciem in memory repo na hash mapach + wsadzenie wiremocka czy w takich już dość zaawansowanych projektach nie ma co walczyć tylko robić jak reszta ?

Ja bym osobiśćie tym bardziej zajął się pisaniem sensownych testów z wiremockami, właśnie szczególnie kiedy internalsy są porypane, bo przy takim teście w ogóle cię to nie interesuje.
A sonar to raczej krzyczy zeby było pokrycie a nie ze każda klasa ma miec test.

@Shalom:
Ale żeby wytestować to po bożemu to z gigantycznego serwisu najłatwiej metodę wydzielić do osobnej klasy czyli np CreateTaskUseCase bo redukujemy zależności do minimum wtedy i łatwo zbudujemy taki UseCase dla testów. A to generalnie spora zmiana pod kątem organizacji projektu i trochę wyłamanie się od "norm". Inni Hindusi mogą się nie połapać. To bardziej problem miękki niż techniczny.

Nie bardzo rozumiem czemu. Jak testuje funkcje systemu to w ogóle nie obchodzi mnie że pod spodem są jakieś klasy. Ja mówię tu o testowaniu w stylu https://github.com/Pharisaeus/almost-s3

No ok ale Ty tu stawiasz apkę i realnie uderzasz przez http.

Ja mówię o testach bez podnoszenia apki.

Jedyne co możesz zrobić, to testować implementacje na "boundries" (np od Controllera do bazy), i olać zupełenie testowanie "wewnętrzne".

Jak już będzie to dobrze otestowane, to można refaktorować i pisać normalne testy.

Bambo napisał(a):

[...] Dodatkowo sonar każe pisac testy do każdej klasy więc siłą rzeczy są te moki wszędzie

Co za idiotyzm.

Zasada jest prosta. Do klasy wstrzykujesz interfejsy, ich implementacja jest zarządzana przez DI (np. Springa) lub ręcznie. Per klasa powinno być góra kilka takich implementacji. W teście każdą z nich mockujesz i testujesz logikę kodu w samej klasie, której instancję tworzysz w tym samym teście. Jeżeli możesz mieć wiele przypadków działania zależności w klasie, to możesz zamockować ich zachowanie na różne sposoby w oddzielnych testach lub jednym sparametryzowanym teście. Nie powinieneś testować działania zamockowanego kodu.

Nie wiem, co masz za aplikację, ale w takim typowo springowym modelu, logikę można jednostkowo przetestować w klasach typu Service. W klasach typu Repository, które korzystają z bazy możesz sobie wpiąć test containery i masz wtedy taki jednostkowo-integracyjny test, który uderza do bazy w Dockerze. Jeśli w Repository jest zewnętrzne API, to pozostaje Ci mockowanie go lub postawienie stub servera HTTP w teście (są różne biblioteki do takich rzeczy). Na poziomie kontrolera możesz napisać springowy test integracyjny i testować go np. WebTestClientem.