[Bruno_]

#java #spring
pomoże ktoś? Nie za bardzo wiem jak powinny te testy wyglądać i jak zrobić żeby działało no i ogólnie czy tak można zrobić

Tutaj obrazki (schemat i jak wyglada zwracany obiekt user): https://imgur.com/a/G4I1FMm

No a tutaj aktualny kod testu: https://paste.ofcode.org/cnip8SKDZpdngyyVTMpCBs

pomyślałem że w sumie to każdą moją klasę mogę sprawdzić własnie takimi mockowymi obiektami (że np wywołuję UserController.addUser(json) z moim jsonem, wiem co powinno wyjść więc mockUserService zwracałby tego usera że niby zapisał i pobrał z bazy danych a w tescie samym sprawdzalbym czy faktycznie to samo wyszlo), ale strasznie duzo kodu musiałbym napisać (do każdej metody w każdej klasie, plus jeszcze weź to pozmieniaj np przy dodawaniu nowego pola w encji) i mam wątpliwości, że przecież muszą być lepsze rozwiązania ¯\_(ツ)_/¯

[Ostrzewtlumie]

@Bruno_: mockujesz serwis zeby zwracal to co chcesz. Czyli odpalasz adduser i mockujesz wszystko to co uzywa servisy itp. Ja bym zaczal testy od sercisow a pozniej controllery. I w sumie nie wiem czy nie odpala sie wtedy testow intergracyjnych na kontrolery dawno w springu nie pisalem.
w tym akurat przykladzie bym zmockowal ten serwis i zrobil ze kiedy odpalana jest metoda adduser z serwisu to zwroc cos.

[doubt]

@Bruno_: po co chcesz testować jednostkowo kontrolery, w których nie ma żadnej logiki? (A przynajmniej nie powinno jej tam być)

[Bruno_]

@doubt no dobra ale w serwisach ten sam problem :( w sumie to wlasnie zaczalem zabawe z tym co dostarcza spring do testowania tj. jakies @DataJpaTest czy cos

Tak szczerze to sie pogubilem troche w tym xD

[doubt]

@Bruno_: zacznij od ustalenia czy piszesz testy jednostkowe czy integracyjne.

Jak jednostkowe, to nie powinny one dotykać springa, bo stawianie kontekstu kosztuje sporo. Wtedy korzystasz tylko z biblioteki do mocków i wstrzykujesz sobie do testowanej klasy mocki zależności zewnętrznych.

To o czym mówisz, czyli MockMvc i inne springowe rzeczy stosuje się w testach integracyjnych gdzie stawiasz cały kontekst (najczęściej z jakąś bazą/brokerem in memory/wiremockiem) i wtedy już testujesz całość na zasadzie,

[Przegrywek123]

@Bruno_: Rób sobie integracyjne testy kontrolerów razem z @SpringBootTest i @RunWith(SpringRunner.class), możesz wtedy stestować praktycznie cały endpoint. Nie musisz wtedy mockować, rzucasz na autowired co chcesz + możesz sobie stworzyć interceptor testowy. (np. jakąś fabrykę z @PostConstruct która ci będzie bazę danych wypełniać przed testem. Mocki są dobre do jednostkowych jak chcesz sprawdzić pojedyńczą logikę (czy np ci prawidłowo stream coś zwróci w przypadkach granicznych. Generalnie przy standardowej architekturze REST

[Bruno_]

@Przegrywek123: tak jest dobrze? https://paste.ofcode.org/ng4ZCuEcsxRQ4CxzkLeXxf

w każdym teście pisałbym to given (tak, żeby testy były niezależne)

[Przegrywek123]

@Bruno_: jak dasz to w @before to i tak przed każdym testem ta metoda jest wywoływana. Jak chciałbys raz to od tego masz @BeforeClass tylko że to jest statyczne

[Bruno_]

@Przegrywek123: no to wiem, mozna też zrobić before class niestatyczne za pomoca @TestInstance(TestInstance.Lifecycle.PER_CLASS)

zostane chyba jednak przy pisaniu given w kazdym tescie zeby nie trzeba bylo scrollowac i szukac w tym bloku before

[Ostrzewtlumie]

@Bruno_ dobrym zwyczajem jest nazywać metody którym dajesz adnotacje @test jako "testmetoda", lub "metodatest".

[Bruno_]

@Ostrzewtlumie: @Przegrywek123: pushnalem juz co prawda xD ale moze byc? https://github.com/Karolcz125/spring-forum/blob/master/src/test/java/unit/user/UserServiceTest.java

@Ostrzewtlumie: po polsku? na pewno nie, nawet po angielsku to nie wydaje mi sie, ogladalem troche ludzi co wyklady z live-codingiem robili, nie spotkalem sie z czyms takim

[Przegrywek123]

@Bruno_: @Ostrzewtlumie: Ja piszę w konwencji
shouldReturnUserIfCorrectCredentials
shouldThrowException
shouldReturnAllWith..
No spoko, popatrz na coverage czy jest dobry i tyle

[doubt]

@Przegrywek123: tak jest dobrze? https://paste.ofcode.org/ng4ZCuEcsxRQ4CxzkLeXxf

w każdym teście pisałbym to given (tak, żeby testy były niezależne)

@Bruno_: Możesz postawić naj klasie @RunWith(MockitoJUnitRunner.class), wtedy cała metoda z @Before będzie zbędna

[Ostrzewtlumie]

@Bruno_: no po angielsku xD np testGetUserId albo testGetUserIdWhenException. Z tym should tez jest dobrze. Zalezy od konwencji ale pisanie nazwy takiej samej jak testowana metoda to tak srednio.