[takiMirek29]

Jeśli piszę testy do restowego api to pisać oddzielnie 1 test do sprawdzenia czy controller zwraca odpowiedni status i 2 test do sprawdzenia zwracanego contentu?
Pierwszy miałby formę np.

 @Test
 void processCreationBook() throws Exception {
 mockMvc.perform(get("/books"))
 .andExpect(status().is2xxSuccessful());
 }

I byłby w klasie BooksControllerIT.

A drugi test, sprawdzający zwracany content w BooksControllerTest.

Ma to sens? W przypadku posta w każdym z tych testów musimy załączyć utworzony obiekt więc mam wrażenie, że 2x robię to samo.
Czy to wystarczy przy testowaniu api?

#java #naukaprogramowania #programowanie #programista15k

[Pharos]

@takiMirek29: Po co testy jak wiesz, że działa. ( ͡° ͜ʖ ͡°)

[Saly]

@takiMirek29: duplikowanie testów, które mają ten sam kod a różne asercje jest bez sensu. Jest taka reguła "one assertion per test", ale to idiotyzm.

[takiMirek29]

@Saly: Niestety nie ma jakiegoś standardu co do tych testów i się gubię gdzie co testować i jak nazywać ( ͡° ʖ̯ ͡°) A każdy tutorial podaje co innego

[Saly]

@takiMirek29: witamy w programowaniu ( ͡° ͜ʖ ͡°) Niestety dużo praktyk/dobrych wzorców jest zła/słaba i trzeba samemu wyrobić intuicję, bo każdy debil może wymyśleć coś z czapy. Często praktyki też trzeba interpretować jak biblię tj. są dobre tylko w niektórych kontekstach a często w przypadku ogólnym powodują więcej szkód niż zysków

[bb89]

@takiMirek29: jak masz duplikacje kodu to pisz oba w jednym miejscu, z tym ze pierwsza asercja powinna być sprawdzająca status code, w przeciwnym wypadku przy failu będziesz miał tylko info ze response jest inny, a status code niewidomo jaki jest.

Ale najlepiej poszukać jakis good practisow, ja nie znaju javy

[PaaD]

@takiMirek29: Sprawdzałbym oba od razu. Może jakiś ortodoks powie że niekoszernie, ale za to jest praktycznie (a to ważniejsze niż fiksacja na jakiś teoretycznych rozkminach). No i pozwala wyrobić fajną konwencję, w której już na pierwszy rzut oka widać jaki to przypadek testowy (gdy będzie tego więcej). Dla obrony koszerności tego rozwiązania: gdzieś pod spodem to i tak jest część odpowiedzi serwera, więc możemy przyjąć że testujemy jednocześnie kilka cech tej

[markaron]

@takiMirek29: A po co testować czy kod odpowiedzi jest 2xx, jeżeli test sprawdzający content z automatu będzie miał 2xx jeżeli się powiedzie, albo inny jeżeli wystąpi błąd. Więc test sprawdzajacy content odpowiedzi, testuje automatycznie czy endpoint zwraca kod 2xx.

[S.....i]

@takiMirek29: testuj od najbardziej ogolnych do szczegolowych asercji, najpierw status, pozniej ilosc elementow (jesli to lista) pozniej sprawdz czy element posiada oczekiwane wlasciwosci, oddzielne przypadki testuj w innych case...

[takiMirek29]

@markaron: @Szubrawski: @PaaD: @bb89: @Saly:
A poza takim szczegółowym (integracyjnym), taki unit test ma sens dla kontrolera?

 @Test
 void shouldReturnCreatedBook() {
 Book book = getBook();
 when(bookService.saveBook(book)).thenReturn(book);
 BookController bookController = new BookController(bookService);
 assertEquals(book, bookController.createBook(book).getBody());
 }

[Saly]

@takiMirek29: sens ma choć wolałbym to przetestować integracyjnie, bo pokryjesz dużo więcej kodu. Kontroler to jednak w większości integracja z serwisem i warto sprawdzić na rzeczywistym serwisie (a nie na mocku) czy oba komponenty dobrze ze sobą współgrają.

[takiMirek29]

@Saly:

A poza takim szczegółowym (integracyjnym), taki unit test ma sens dla kontrolera?

integracyjnie właśnie będę testował w osobnym teście i tam ze szczegółami z jedynym mockiem bookrepository -> do tego pytanie, czy robi się też testy zapisujące do bazy i sprawdzające to co zwróci? Np. na h2

[Saly]

czy robi się też testy zapisujące do bazy i sprawdzające to co zwróci? Np. na h2

@takiMirek29: tak i to na normalnych bazach. Przy typowym serwisie uderzającym do bazy takie testy to w sumie najważniejsza część bo według mnie testy uderzające do bazy dają dużo więcej korzyści niż czyste unity

Ja wolę generalnie podejście top down i testują tak wysoko jak się tylko da (E2E, integracyjnie) schodząc dopiero wtedy, gdy uznam,

[markaron]

@takiMirek29: Pytanie czy za tym endpointem kryje sie jakas złożona logika biznesowa. Jesli tak to warto przetestować tą logikę jednostkowo. Jezeli nie ma tam nic zlozonego, czyli zwykla walidacja pól, czy null, empty lub wieksze od 0 i insert do bazy, to zwykły test integracyjny czy sie zapisało wystarczy.

[draxgar]

Niestety nie ma jakiegoś standardu co do tych testów i się gubię gdzie co testować i jak nazywać

@takiMirek29: są standardy, nazewnictwo. Popatrz sobie na ISTQB.

Jeśli piszę testy do restowego api to pisać oddzielnie 1 test do sprawdzenia czy controller zwraca odpowiedni status i 2 test do sprawdzenia zwracanego contentu?

Nie. Jeden test, sprawdzający, czy na dany request dostałeś odpowiednią odpowiedź HTTP i body.

To oczywiście, jak robisz test integracyjny.