테스트 코드,,,의 중요성을 간과한 채 개발하던 시절이 있었다.
시간도 부족했고, 테스트 코드 작성법을 또 따로 공부하기 귀찮았기 때문이다.
굳이 테스트를 하자면 Service 계층이나 Repository 계층에 관련해 짧게 짧게 테스트 코드를 작성했던 것 같다.
반면, Controller 계층은 어떻게 테스트를 해야하나 의문이었다.
HTTP 요청을 보내고 HTTP 응답을 확인해야하는데, 그에 대한 방법을 알지 못했다.
그래서 우린 항상 Postman을 통해서 API마다 요청을 보내고 응답을 확인했다.
API 테스트에서 오류가 발생하면 컨트롤러, 서비스, 레포지토리까지 확인해가면서 오류가 어디서 발생했나 확인해야 했다.
그나마 서비스나 레포지토리 중 테스트 코드를 간단하게나마 작성한 곳이 있다면 오류를 찾기에 조금 더 수월했었다.
하지만 그래도 번거로운 건 번거로운 것이었기 때문에 우리는 컨트롤러 계층까지 완벽히 테스트할 무언가를 찾다고 Mock에 대해서 어렴풋이 듣게 되었다.
이제서야 Mock에 대해 공부하게 된 것이 아쉬울 따름이다.
Mockito는 개발자가 동작을 직접 제어할 수 있는 가짜(Mock) 객체를 지원하는 테스트 프레임워크이다.
스프링으로 웹 애플리케이션을 개발하면 여러 객체 간의 의존성이 생긴다.
이러한 의존성은 단위 테스트 작성을 어렵게 하는데, 이를 해결하기 위해 가짜 객체를 주입시켜주는 Mockito 라이브러리를 활용할 수 있다.
@InjectMocks
private MemberController target; // 테스트할 타겟 객체
@Mock
private MemberService MemberService; // 의존성이 있는 객체
서블릿 컨테이너의 구동없이 시뮬레이션된 MVC 환경에 모의 HTTP 서블릿 요청을 전송하는 기능을 제공하는 유틸리티 클래스이다.
이를 통해 컨트롤러를 테스트할 수 있다.
MockMvc가 제공하는 메서드로, 브라우저에서 서버로 URL 요청을 하듯 컨트롤러를 실행시킬 수 있다.
RequestBuilder 객체를 인자로 받고, 이는 MockMvcRequestBuilders의 정적 메서드를 이용해서 생성한다.
GET, POST, PUT, DELETE 등의 요청 방식과 매핑되는 get(), post(), put(), delete() 메서드 등을 제공한다.
이 메서드들은 MockHttpServletRequestBuilder 객체를 리턴하고 이를 통해 HTTP 요청 관련 정보(헤더, 쿠키, 파라미터 등)를 설정할 수 있다.
perform() 메서드를 이용하여 요청을 전송하면 그 결과로 ResultActions 객체를 리턴하는데, 이 객체는 응답 결과를 검증할 수 있는 andExpect() 메서드를 제공한다.
andExpect()가 요구하는 ResultMatcher는 MockMvcResultMatchers에 정의된 정적 메서드를 통해 생성할 수 있다. (isOk(), isNotFound(), isInternalServerError() 등...)
각각에 대한 자세한 코드들은 TDD 프로젝트 글 목록에 작성되어 있다.
참고하길 바란다.!