[UnitrA]

Mam taką metodę:

@PostMapping
 ResponseEntity saveCar(@RequestBody Car car) {
 logger.info("Request for add car got");
 return ResponseEntity.ok(repository.save(car));
 }

która działa bez problemu, ale jak próbuję ją testować, to otrzymuję taki response z pustym body i nie wiem czemu?

MockHttpServletResponse:
 Status = 200
 Error message = null
 Headers = []
 Content type = null
 Body = 
 Forwarded URL = null
 Redirected URL = null
 Cookies = []

#naukaprogramowania #spring

[UnitrA]

@LazyInitializationException:

@RunWith(SpringRunner.class)
@SpringBootTest
@AutoConfigureMockMvc

[UnitrA]

@LazyInitializationException: no właśnie siedzi, tutaj jeszcze reszta z konsoli:

MockHttpServletRequest:
 HTTP Method = POST
 Request URI = /api/cars
 Parameters

[UnitrA]

@LazyInitializationException: no właśnie, jak testuję GET i PUT to normalnie zwracają jsona, a tu próbuje już wszystkiego i nie wiem, co robię źle ( ͡° ʖ̯ ͡°). Ale skoro metoda saveCar działa, to coś w teście jest skopane

[UnitrA]

@LazyInitializationException: w konsoli, tak? Zrobiłem i mi zwróciło jsona

[kto3]

@UnitrA: czemu w teście integracyjnym mockujesz repozytorium? W integracyjnym się tego przeważnie stara unikać, żeby wyłapać też różne błędy na poziomie integracji z bazą.
Moim zdaniem w teście repozytorium nic nie zwraca bo obiekt car z mocka, nie jest tym samym obiektem który został zmapowany z jsona w controllerze.
Skoro korzystasz z repozytorium i koniecznie nie chcesz używać prawdziwej bazy, to zrób sobie do testów klasę która będzie to repozytorium

[UnitrA]

@kto3: bo tak było w tutkach i uznałem, że ma to sens, baza może przecież mieć różną postać i nie chciałem, żeby test był od niej zależny.
Test miał przetestować tylko metodę kontrolera,
wczoraj w końcu zadziałał, po tym jak zmieniłem
when(carRepository.save(car1)) na when(carRepository.save(ArgumentMatchers.any())
@LazyInitializationException:

[kto3]

@UnitrA: no to jeśli już koniecznie chcesz unikać bazy, to zamiast mocka zrób swojego stuba.

[kto3]

@LazyInitializationException: odkąd mock jest szybszy od realnego obiektu?

[kto3]

@LazyInitializationException: no jak widać na powyższym przykładzie, nie zawsze. Na pewno jest dużo prościej zrobić mocka, ale jeśli coś się zepsuje i nie będzie działał tak jak tego oczekujemy, to znalezienie błędu jest trudniejsze.

Ja i tak jestem zdania, że jak w teście sprawdzamy czy spring działa, to powinniśmy sprawdzić też czy baza dobrze współpracuje. Mocki, stuby czy inne fikołki są dobre w testach jednostkowych.

[kto3]

@LazyInitializationException: zgadzam się, tylko różnica jest taka, że stuba łatwiej zdebugować niż mocka