@ControllerAdvice기능을 확인하기 위한 테스트코드에서 발생한 트러블 슈팅

 오늘은 개인프로젝트에 @ControllerAdvice를 추가해서 유효하지 않은 파라미터를 공통으로 처리해주는 작업을 하고 있었다. 테스트코드 작성해서 테스트하는데 분명 제대로 작성했는데 @ControllerAdvice가 적용되지 않는 것이었다. @ControllerAdvice가 다른 패키지에 있었는데, 혹시나 해서 컨트롤러 안에 @ExceptionHandler 메서드만 넣으니까 잘 작동하고.

@ControllerAdvice가 작동하지 않았던 경우

@ControllerAdvice가 제대로 작동한 경우

 위 이미지를 비교해보면 알 수 있듯이 제대로 작동하지 않은 경우에는 DefaultHandlerExceptionResolver로 BindException이 처리됐고, 제대로 작동한 경우에는 ExceptionHandlerExceptionResolver로 처리가 됐다. DefaultHandlerExceptionResolver는 스프링 내부적으로 발생하는 주요 예외를 처리해주는 그야말로 Default인데, 그말인즉 @ControllerAdvice를 알지 못해서 Exception을 처리해줄 녀석으로 DefaultHandlerExceptionResolver가 선택된 것이다. 그렇다면 왜 컨트롤러 밖에 @ControllerAdvice로 Exception을 처리해주려고 하면 @ExceptionHandler가 작동하지 않은 것일까?

 이거 알아내느라 몇 시간이나 걸렸는데 결국은 컨트롤러 테스트시 mockMvc를 어떻게 만들어주느냐 때문이었다. 디버깅도 해보고 비슷한 오류를 찾아 인터넷을 헤매다가 찾은 답이 아래와 같다. 중요한 부분은 mockMvc를 WebApplicationContext로 만들어주는 부분.

 기존 내 코드는 아래와 같았다. 나의 경우, 컨트롤러만으로 MockMvc를 만들어서 테스트에 사용하고 있었는데, 그러다보니 스프링 구성이 포함되지 않아 @ControllerAdvice가 제외되어 결과적으로 DefaultHandlerExceptionResolver가 사용된 것으로 보인다.

작동하지 않았던 코드

잘 작동하는 코드

 스택오버플로우에서 저 글을 보지 않았더라면 몇 시간이나 더 헤맬뻔... 제일 먼저 영어로 검색해보는 습관을 들이자.