Wpis z mikrobloga

@Nofenak: nie testuje się controllerów unitowo tylko integracyjnie, więc żadne mockMVC. Zero mockowania w warstwie controllera, serwisów czy repozytorium, jedynie deep stuby do jakichś zewnętrznych serwisów (mock na RestTemplate czy innego klienta http)

A i co do repo to kiedyś stosowało się H2/inMemory DB ale teraz najlepiej stawiać TestContainers dockerowe takie coś
@nad__czlowiek: czyli mając sytuację, gdzie z domeny możesz zwrócić jakiś wynik lub X błędów gdzie potencjalnie masz to obsłużyć różnymi statusami/redirectami/kodami błędów to dla każdego takiego przypadku piszesz test integracyjny czy nie testujesz ich w ogóle ( ͡° ͜ʖ ͡°)?
Chyba że masz kupę logiki w kontrolerach, wtedy to można testować ( ͡° ͜ʖ ͡°)


@Endriu_: mi przelozony mowil ze oni maja tyle logiki w controllerach no bo przeciez klikasz to na wygladzie wiec to musi byc w controlerze logiczne nie ( ͡º ͜ʖ͡º)
@maciekkkkk: pytanie bo co chcesz zwracać X błędów?

Przecież nawet ze względów bezpieczeństwa lepiej zwrócić na fronta prostą 400/500 "error" (jak masz jakieś błędy to i tak front nie musi o tym wiedzieć, po prostu używasz logowania), a nie wysyłać jakieś specyficzne wiadomości typu 422 "invalid password/mail" - w ten sposób tylko pomagasz włamać się na stronkę.
@Nofenak: niczego, kontrolery testuje się integracyjnie. Bazę stawiasz jako testcontainer, zewnętrzne serwisy stubujesz przez wiremocka.

Dzięki temu aplikacja uruchamiana w ramach testów integracyjnych jest praktycznie jeden do jednego odwzorowaniem tego, co się dzieje na produkcji.

Wszelkie mocki, Mockito, a już zwłaszcza PowerMock należy #!$%@?ć prądem.