기존 필터 단위 테스트의 문제점
Mocking된 HttpServletResponse
mockito로 정의한 response의 응답이 테스트 결과 필요하다고 생각했다. 그 이유는 OncePerRequestFilter를 상속한 JwtAuthenticationFilter가 특정한 예외상황이나 문제점이 발생했을 때 예외가 실제 핸들링이 되었는지 알 필요가 있었다. 그래서 실제 응답을 잘 전달했는지 파악하기 위해서는 response의 status가 잘 설정되었는지 알 필요가 있었다.
기존의 코드에는 HttpServletResponse를 단순히 mock을 이용해 가짜 객체를 주입했다. 이것의 문제점은 객체 자체가 가짜 객체이므로 getStatus()를 하더라도 0이 나오고, 모든 메서드를 stubbing 하는 것은 실제 코드가 테스트상 잘 동작하는지 정확히 반영하지 못했다.
SPY를 활용해서 해결하기
mock의 문제점은 객체 자체를 프록시를 이용해 가상 객체를 생성하는 점이다. 이 때 모든 객체는 동작이 null이거나 0이거나 실제 타입을 정의하지 않았을 때 default value를 리턴한다. 그러나 spy를 활용하면 실제 객체의 동작과 상태는 활용하면서 특정 메서드만 stubbing이 가능했다.
하지만 문제점은 spy를 제대로 활용하려면 interface에 spy를 적용하면 안된다. interface는 구현체가 아닌 메서드만 정의해 놓은 타입으로 여기에 spy를 적용하면 mock과 같이 단순히 가짜 프록시 구현체를 생성할 뿐이다.
가짜 구현체 만들기
실제 구현체를 찾아서 주입하는 방법도 있지만 이 경우 실제 Fiter에서 해당 구현체만을 명확히 사용하는지 확실하게 파악해야 한다. 이 부분이 쉽지 않았기 때문에 Fake 구현체를 만들기로 했다.
이 중에서 내가 짠 필터의 단위 테스트의 경우 Response의 status가 알고 싶었기 때문에
getStatus()와 setStatus() 그리고 status 상태를 두었다.
실제 테스트 해보기
spy를 활용해 FakeHttpServletResponse 객체를 활용한 프록시 객체를 생성한다.
그 이후 테스트를 수행하면 실제 코드 내부에서 setStatus()가 문제 없이 동작하고 해당 status를 테스트 코드에서 가져와도 잘 동작한다..!
