Siemka. Jak powinien wyglądać dobry test integracyjny restowego api? Czy przed każdym testem, powinienem czyścić bazę ( jeśli na niej operuje ) ? Czy sprawdzać zarówno treść odpowiedzi, jak i zawartość bazy po zapytaniu ( post/put itp. ) ? Czy wykorzystywanie repozytoriów do przygotowywania bazy to znacznie gorsze rozwiązanie niż sqlowe skrpyty ? Wiadomo, że na pewno zależy to od wielu czynników, ale chciałbym wiedzieć jak to wygląda w praktyce. Aplikację piszę dla siebie, a z racji powolnego tempa rozwoju zależy mi na jak najlepszych testach. Z góry dzięki za pomoc ;)
1
1
Podstawowe pytanie czy zalezy Ci rowniez na tescie bazy czy nie ? Bo moze dobrym rozwiazenim bedzie jakas in memory SQL ?
0
WhiteLightning napisał(a):
Podstawowe pytanie czy zalezy Ci rowniez na tescie bazy czy nie ? Bo moze dobrym rozwiazenim bedzie jakas in memory SQL ?
Do testów wykorzystuję H2. Zależy mi na tym by mieć pewność jaki jest ostateczny rezultat.
3
DamianSn napisał(a):
Czy przed każdym testem, powinienem czyścić bazę ( jeśli na niej operuje ) ?
W teorii tak. W praktyce może to być zbyt wolne i trzeba kombinować z pisaniem tak testów, żeby nie wpływały na siebie wzajemnie.
DamianSn napisał(a):
Czy sprawdzać zarówno treść odpowiedzi, jak i zawartość bazy po zapytaniu ( post/put itp. ) ?
Testy integracyjne powinny być maksymalnie czarnoskrzynkowe, więc nie powinieneś sprawdzać zawartosci bazy po zapytaniu. Idealne testy integracyjne używające REST API powinny dalej działać jeśli zamienisz relacyjną bazę danych Cassandrą, Redisem lub własną implementacją opartą na HashMapie
3
Jeśli rzeczywiście zależy Ci na tym żeby mieć pewność, co dokładnie zostało wsadzone do bazy danych to jesteś w stanie to zrobić jakimś toolem typu AssertJ-DB albo dbUnit. Z doświadczenia wiem, że takie rozwiązanie powoduje tylko zwiększenie poziomu kruchości testów (fragile tests), więc trzeba z tym ostrożnie. Mała zmiana w modelu danych spowoduje konieczność zmian w wielu testach. No i dochodzi jeszcze kwestia szybkości wykonywania tych testów - czyszczenie bazy za każdym testem naprawdę zwielokrotnia czas wykonania całości.
Zgeneralizowałbym to tak, że im więcej masz testów, tym trudniej utrzymać whiteboxowe asercje bazy danych, więc tym mniej się to opłaca w dłuższej perspektywie.
Pracowałem przy produkcie, w którym wprowadziliśmy takie asercje w testach z pomocą dbUnita, ale już przy kilkuset testach dopadły nas wyżej wymienione problemy i po prostu nie opłacało się tego utrzymywać. Doszliśmy do wniosku, że nabardziej opłaca się pisać czarnoskrzynkowe testy RESTowe na odpalonej aplikacji z pomockowanymi zdalnymi systemami (WireMock).