간단하게 말하면, 테스트를 작성했다.
@WebMvcTest 를 이용한 웹 레이어 테스트@AutoConfigureMockMvc 를 이용한 통합 테스트Controller, Service, Repository 가 있다. 이를 레이어 별로 나눠서 잘 테스트할 수 있다면, 해당 레이어는 다른 레이어의 영역에 침범하지 않는 것으로 간주할 수 있다.Mock 을 적극 활용하면 테스트 대상 코드를 격리할 수 있다.Mock 을 이용한 격리는 상호작용하는 다른 객체가 올바르게 값을 준다는 가정 하에 이뤄지는 테스트이니 꼭 통합 테스트로 다시한번 검증해보자.spy(), given(), verify(), eq(), any() 등 어떤 객체든 흉내낼 수 있는 다양한 메서드를 제공한다.Service 레이어에서는 Mocking 없이 꼼꼼한 유닛 테스트로 동작을 보장했다.Controller 레이어에서는 Controller 에 정상적인 Service 가 주입되어 있다고 가정하에 Controller 객체가 올바르게 동작하는지 테스트했다.Web 레이어에서는 mockMvc를 이용해서 실제로 HTTP 요청을 하는 것처럼 테스트를 해보았다.ParameterizedTest 고려의 필요성
ParameterizedTest 의 경우, 아직 한번도 사용해본 적이 없는데, 특정한 파라미터가 오면 이뤄지는 동작이라는 것을 더 강조하고 싶을 때 사용해보면 괜찮을 것 같다.
위에서는 task.setTitle() 에 오는 파라미터에 따라 달라지는 동작을 표현했으면 더 좋았을 것 같다.

잘못된 이라는 단어는 구체적이지 않다. 존재하지 않는 ID, 형식에 맞지 않는 ID 등으로 테스트의 목적을 작성할 때는 더욱 구체적으로 작성해보자.

위에서 taskArgumentWithTitle 은 사실 딱히 길게 쓸 이유는 없는 변수명이다. 너무 길게 지어서 쓸데 없는 주의를 끌지 말자.
@Service 를 테스트할 때 통합 테스트와 Mock 테스트 어떤 것을 우선시 해야하는가?@WebMvcTest 를 사용하고 Service 에 대해 @MockBean 을 사용하는 것@SpringBootTest 와 @AutoConfigureMockMvc 를 사용하는 것