서블릿 컨테이너를 전체 다 띄우지 않으면서 HTTP요청 테스트를 진행함. 디스패쳐서블릿은 실제로 호출된다. 스프링의 디스패쳐서블릿 → 핸들러 매핑 → 핸들러 어댑터 → 컨트롤러 → 뷰리졸버 → 메시지 컨버터로 이어지는 실제 처리 흐름은 그대로 따라감.

두 가지 셋업 방식

MockMvc 인스턴스를 만드는 방법은 크게 두 개임. 첫 번째는 TestContext 프레임워크를 통해 Spring MVC 설정을 로드하여 WebApplicationContext를 테스트에 주입받는 방식.

• standaloneSetup: 컨트롤러 하나를 직접 넘겨 최소 구성만만 띄운다. MockMvcBuilders.standaloneSetup(new MyController()).build() 형태로, Spring 컨텍스트를 로드하지 않아 빠르지만 실제 설정과 차이가 날 수 있다.
• webAppContextSetup: @WebAppConfiguration + WebApplicationContext를 로드해 실제 설정에 가깝게 검증하는게 목적.

Spring Boot의 편리함 - @WebMvcTest

역시나 부트는 @WebMvcTest 라는 간단한 애너테이션을 제공한다. 이건 컨트롤러 빈, 필터, 컨버터, @ControllerAdvice 등 Web MVC 관련 빈만 초기화하고 service/repository/component 빈은 초기화하지 않는다. 따라서 @WebMvcTest로 테스트를 작성할 때는 테스트 대상이 아닌 컨트롤러의 협력 객체를 @MockBean(현재는 @MockitoBean)으로 목킹하는 패턴을 주로 사용함. 그리고 Spring Boot가 @WebMvcTest 사용 시 MockMvc를 자동 구성해 준다.