간단하게 말하면, 테스트를 작성했다.
@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
를 사용하는 것