Poprawny test integracyjny

Odpowiedz Nowy wątek
2019-09-10 10:04
1

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 ;)

Pozostało 580 znaków

2019-09-10 10:27
1

Podstawowe pytanie czy zalezy Ci rowniez na tescie bazy czy nie ? Bo moze dobrym rozwiazenim bedzie jakas in memory SQL ?

Pozostało 580 znaków

2019-09-10 10:32
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.

edytowany 1x, ostatnio: DamianSn, 2019-09-10 10:35

Pozostało 580 znaków

2019-09-10 10:51
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


Pozostało 580 znaków

2019-09-10 15:15
c3r

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).

edytowany 2x, ostatnio: c3r, 2019-09-10 15:20

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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