Cześć.
Zabrałem się za pisanie małej aplikacji w ramach rozwoju. Mało w życiu pisałem testów, chciałbym je podszkolić( i nie tylko testy, ale to na inny wątek). Póki co, jako framework do testów wybralem Junit(Tak wiem, mogłem też Spocka, ale póki co wyszło, że chce Junit). W związku z tym, że chce je podszkolić, chciałbym Was podpytać o dobre praktyki. Jak np testować controllery(wystawione resty), fasady, czego używacie, jak powinno się testować zapisywanie danych? Czy stosujecie implementację własną w pamięci jako np. mapa? Czy korzystacie z rozwiązań typu test containers? Czy uslugi restowe testujecie np MockMvc, czy w jakiś inny sposób? Jak testujecie poszczególne rzeczy? Jeśli o czymś zapomniałem, to liczę, że w komentarzach dorzucicie swoje trzy grosze.
Głównie praktyki z testów nabierałem z tego kursu udemy:
https://www.udemy.com/course/testing-spring-boot-beginner-to-guru/
Cześć.
Do testów jednostkowych używam Junit 5 + mockito.
Do testów integracyjnych w aplikacjach webowych używam Junit 5 + Wiremock + Rest Assured
Dobrą praktyką jest unikanie mockowania. Niektórzy tak dużo mockują, że ich testy same przypominają imitacje. Tworzenie mocka ma odrębną często skomplikowaną logikę, którą trzeba dodatkowo utrzymywać, przez co z czasem w ogóle przestają testować właściwą logikę.
baryel napisał(a):
Dobrą praktyką jest unikanie mockowania. Niektórzy tak dużo mockują, że ich testy same przypominają imitacje. Tworzenie mocka ma odrębną często skomplikowaną logikę, którą trzeba dodatkowo utrzymywać, przez co z czasem w ogóle przestają testować właściwą logikę.
Zalecasz tworzenie rzeczywistych obiektów?
To jest szeroki temat, filozofii jak pisać testy jest mnóstwo dlatego na początek testy należy pisać w taki sposób w jaki pisze je zespół.
LitwinWileński napisał(a):
To jest szeroki temat, filozofii jak pisać testy jest mnóstwo dlatego na początek testy należy pisać w taki sposób w jaki pisze je zespół.
Miałem taką sytuacje:
Mój kod nie przechodzi jednego testu - poprawiam.
Mój kod nie przechodzi innego testu - patrzę w kod testów ...
nie ma mowy aby jakikolwiek kod przeszedł oba :)
O laboga.... kolejny wątek o testach. Zdania są podzielone, delikatnie rzecz ujmując.
Moje skromne zdanie: nie ma większego znaczenia, czy użyjesz takiej, czy innej biblioteki do testowania, czy użyjesz mocków, czy ich nie użyjesz, tak długo jak twoje testy są w stanie ciebie przekonać, że aplikacja działa.
Bardzo dużo jest kategorycznych twierdzeń typu "mocki to zło", "testuj pakiet a nie bebechy" itp. Czasami trzeba coś zamockować i nie ma najmniejszego znaczenia czy będzie to jakiś WireMock, Mockito, czy ręcznie dopisana klasa wyłącznie pod testy (tylko jak przetestujesz tę klasę i po co się męczyć z jej pisaniem?).
Jeżeli piszesz aplikację wystawiającą REST API, to moim zdaniem najrozsądniej jest zacząć od testowania jej zachowania, pisząc testy przypadków, których spodziewasz się na produkcji. Inni wolą testowanie zacząć od kontrolera, pomijając całą warstwę web, a jeszcze inni będą pisać testy do każdej klasy na każdej możliwej warstwie i obudowywać każdą z tych "testowanych" klas mockami tego ostatniego naprawdę nie polecam.
Spring ma swoje własne narzędzia wspomagające testowanie i jak już ktoś pisze w tym frameworku, to warto z nich korzystać.
Do przeczytania: https://spring.io/guides/gs/testing-web/