Server Jetty/Jersey a Testy

0

Czy jest jakiś ludzi sposób aby napisać testy aplikacji napisanej z serwerem Jetty/Jersey + Rest? Chodzi mi o napisanie np Junit testów wołąjacych resty ale wymagało by to wystartowanie aplikacji.

0

Mam takie testy niestety w kodzie prywatnym - z tego co pamiętam około 100 do 200 ms na startowanie serwera (pytanie co tam masz). Da się przeżyć.
Tu jest dyskusja:
https://stackoverflow.com/questions/29758607/how-to-run-jetty-server-for-java-junit-testing

Ale przyznaje, że przeniosłem się z nowymi rzeczmi na Ratpack -> start serwera 10-16 ms. To już zupełnie fajnie (ale to nie servlety - dla mnie akurat zaleta).

1

Dzięki za pomoc, ale ogarnąłem to przy pomocy tego: http://memorynotfound.com/test-jersey-rest-service-with-junit/ :)

0

W praktyce ja Web Service REST nieważne czy MVC czy Jersey ze Springiem testuje zwyczajnie integracyjnie za pomocą:

  • rest assured (walidacja api)
  • czasami sprawdzam co się zmieniło w kodzie zarządzanym przez kontekst springa np. stan bazy danych przed i po (embeeded baza odpalana dla każdego testu)
  • zewnętrzne usługi rest mockuje za pomocą WireMock (to tak naprawdę wystawia zewnętrzny serwer HTTP na potrzeby mocka zależnego API)

Dla mnie czas wstawania serwera to nie jest problem bo przecież testy integracyjne są zwykle opalane na żądanie (rozdzielone od szybkich unitów). A jednostkowe testowanie REST API moim zdaniem nie ma sensu: za dużo rzeczy może się zepsuć. Co innego w przypadku typowej logiki, gdzie unity są super. W każdej aplikacji jest też ich znacznie więcej jak testów integracyjnych. Ale nie nadają się do REST API.

0

Ciekawe doświadczenia @margor90. Ja mam natomiast zagwostkę. Mogę w testach integracyjnych stawiać kontekst aplikacji i wołać do endpointów kontrolera przez jakiś serwer http, np rest assured (czysta baza danych). Później po lekkiej konfiguracji mogę użyć tych samych testów do testowania już zdeployowanej aplikacji (produkcyjna baza danych). Dzięki temu utrzymuję jedno drzewo testów. Minusem jest kobylastość rozwiązania i wolne uruchamianie pojedyńczych testów

W większości serwisów jednak widzę inne rozwiązanie. Testy integracyjne api obejmują mockowanie, a testy właściwe są wykonywane na działającej aplikacji do której uderza zewnętrzny serwis testując RESTowe endpointy. Trochę mnie zastanawia co w tym przypadku testują testy integracyjne. Jaka jest ich wartość...

1

Dla mnie aby test integracyjny miał wartość przynajmniej w środowisku mikro-usług powinien on:

  • w miarę możliwości przynajmniej testować end-to-end proces w kontekście wywołania, w zasięgu jednej mikrousługi (stan po przejściu wywołania, interakcje z innymi modułami), może być mniej szczegółowy jak unity, ale obejmować spory scope, wiele różnych asercji mile widzianych
  • interakcje z innymi mikrousługami warto i tak przetestować tzw. @MockBean w Spring Boot test normalnie przy użyciu Mockito (np. czy do producenta kolejki wpadają spodziewane obiekty na samym wyjściu usługi)
  • sporadycznie zdarza mi się pisać testy integracyjne o niskim scope np. sprawdzające czy zawiodła walidacja (trochę jak unit, jednak z użyciem kontekstu): przykładowo czy przy odpowiednich warunkach failuje bean validation, test end-to-end w scope mikrousługi / modułu oczywiście obejmuje happypath, ale jak wyłączymy walidację to możemy tego nie wykryć
  • testy jedostkowe są super do logiki i warunków brzegowych np. algorytmy, if-ki itp.
  • i tak trzeba testować end-to-end jak pracują usługi między sobą i czy całość działa (ale to już testy raczej akceptacyjne)

1 użytkowników online, w tym zalogowanych: 0, gości: 1