MockMvc vs End-to-End Tests

MockMvc는 spring-test module의 Servlet API mock 구현 위에 구축되어 있으며 실행 중인 컨테이너에 의존하지 않습니다. 따라서 실제 클라이언트와 라이브 서버가 실행 중인 완전한 end-to-end integration test와 비교했을 때 몇 가지 차이점이 있습니다.

이를 생각하는 가장 쉬운 방법은 빈 MockHttpServletRequest로 시작하는 것입니다. 여기에 무엇을 추가하느냐에 따라 요청이 결정됩니다. 여러분을 놀라게 할 수 있는 점은 기본적으로 컨텍스트 경로가 없고, jsessionid 쿠키가 없으며, forwarding, error, 또는 async dispatch가 없고, 따라서 실제 JSP 렌더링도 없다는 것입니다.

대신 "forwarded" 및 "redirected" URL은 MockHttpServletResponse에 저장되며 expectation으로 검증할 수 있습니다.

이는 JSP를 사용하는 경우 요청이 forward된 JSP 페이지를 검증할 수는 있지만 HTML은 렌더링되지 않는다는 것을 의미합니다. 다시 말해, JSP는 호출되지 않습니다. 그러나 forwarding에 의존하지 않는 Thymeleaf와 Freemarker 같은 다른 렌더링 기술은 기대한 대로 응답 본문에 HTML을 렌더링합니다.

@ResponseBody 메서드를 통한 JSON, XML 및 다른 포맷의 렌더링도 마찬가지입니다.

또는 Spring Boot의 @SpringBootTest를 사용한 완전한 end-to-end integration testing 지원을 고려할 수도 있습니다. Spring Boot Reference Guide를 참고하십시오.

각 접근 방식에는 장단점이 있습니다. Spring MVC Test에서 제공하는 option들은 고전적인 단위 테스트에서 완전한 integration testing까지 이어지는 스케일의 서로 다른 지점입니다. 분명한 것은 Spring MVC Test의 어떤 option도 고전적인 단위 테스트 범주에 속하지는 않지만 그쪽에 조금 더 가깝다는 점입니다.

예를 들어, 컨트롤러에 mocked 서비스를 주입하여 웹 레이어를 분리할 수 있으며, 이 경우 상위 레이어와 분리된 상태에서 데이터 액세스 레이어를 테스트하듯 실제 Spring 설정과 함께 DispatcherServlet을 통해 웹 레이어만 테스트하는 것입니다. 또한 standalone setup을 사용하여 한 번에 하나의 컨트롤러에 집중하고 이를 동작시키는 데 필요한 설정을 수동으로 제공할 수도 있습니다.

Spring MVC Test를 사용할 때 또 하나의 중요한 차이점은 개념적으로 이러한 테스트가 서버 사이드 테스트라는 점으로, 어떤 핸들러가 사용되었는지, 예외가 HandlerExceptionResolver로 처리되었는지, 모델의 콘텐츠가 무엇인지, 어떤 바인딩 에러가 있었는지 및 기타 세부 사항을 확인할 수 있다는 것입니다. 이는 실제 HTTP 클라이언트를 통해 테스트할 때처럼 서버가 불투명한 상자가 아니므로 expectation을 작성하기가 더 쉽다는 것을 의미합니다.

이는 일반적으로 고전적인 단위 테스트의 장점으로, 작성, 추론, 디버그가 더 쉽지만 완전한 integration test의 필요성을 대체하지는 못합니다. 동시에 응답이 확인해야 할 가장 중요한 것이라는 사실을 잊지 않는 것이 중요합니다. 요약하면, 동일한 프로젝트 내에서도 여러 스타일과 전략의 testing이 공존할 여지가 있습니다.