MockBean, SpyBean 을 지양해야 하는 이유

검증을 위해 만든 junit 이 점점 느려진다?

 

내가 만든 기능의 정확성을 올리기 위함과 동시에 회귀 테스트를 위해 만든 나의 단위 테스트가 기능이 많아질수록 점점 더 느려지는 현상을 발견했습니다.

빠른 피드백을 통해 문제 확인을 위해 만든 단위 테스트였는데 오히려 단위 테스트 때문에 CI/CD 연결을 한 프로젝트여서 pr 을 요청할때마다 느립니다.

심지어 hotfix 를 나가야한는 상황에서도 오래 걸리는 테스트 수행 시간까지 최종 확인하는 시간이 지연될 수 있습니다.

(진짜 급한경우 제대로 TDD 가 되지 않은 상태에서 나가 혹시나 나의 변경사항으로 다른 기능에 문제가 있는거 아닌가 불안한에 떨며 반영을 해야하는 이런 말도안되는 상황이 올 수 있습니다.)

 

가장 큰 문제는 MockBean 과 SpyBean 의 남용

 

jUnit 테스트를 하게 되면 우리는 주로 MockBean 과 Spybean 을 사용하게 됩니다.

원하는 코드를 실행하기 위해 객체를 직접 생성하는 방식이 아닌 Mocking 객체를 기존 객체를 대체하여 bean 으로 등록하여 사용하는 것입니다.

주로 우리는 외부 API 를 호출해야 할 때나 테스트하기 어려운 대상을 위주로 이렇게 Mocking 하여 처리합니다.

이를 통해 예상된 데이터를 제공해주기 위해 우리는 그동안 잘 사용해왔을 겁니다.

하지만 이를 통해 우리는 검증을 위한 코드 품이 점점 낮아지는걸 장시간 build 를 통해 체감하게 됩니다. (저처럼요)

 

Spring Context Reload 현상

 

Junit Test 를 사용하는데 우리는 @SpringBootTest 를 사용할 것이며, 해당 테스트를 실행할 때 올라오는 Spring Context 의 로딩 시간이 길다는 것을 느낄 것입니다.

Spring Context 로딩시간이 긴 이유는 프로젝트에 BeanFactory 를 통해 Client 가 설정한 Bean 객체가 DI 로 물려있어 주입을 해야하는데 시간이 소요되기 때문입니다.

이렇게 생성된 Application Context 는 SpyBean과 MockBean 을 사용하는 경우 아쉽게도 Mocking 한 객체 한정으로 대체되는 것이 아니라 Bean 객체에 의존하는 모든 Bean 들을 다시 reload 하여 재주입합니다.

우리가 원하는 결과를 가져오기 위해 (혹은 테스트를 편하게 하기위해) 만든 Mocking 객체로 인해 우리는 긴 Spring Context 시간을 다시 마주해야 합니다.

작은 프로젝트일 경우, 크게 체감하지 못할 것이지만 프로젝트의 규모가 커질수록 검증 품질이 낮아지고 있는 것을 발견할 것입니다.

 

Smell Code 가 많아질 수 있음

 

테스트가 어려운 객체를 Mocking 해야하는데 불필요한 객체를 Mocking 하여 정말 테스트가 필요한 부분을 놓치는 잘못된 사례가 발생할 수 있습니다.

Mocking 한 객체에서 장애가 발생하면 그건 잘못된 테스트를 했기 때문이라 Junit 에 대한 신뢰성이 낮아질 수 밖에 없습니다.

 

사용하지 말라가 아닌 지양일 뿐입니다. 나를 게으르게 만드는 요소를 제거하면 됩니다.

 

그럴 일은 없겠지만 게으른 개발자들이 주로 하는 실수라고 생각합니다. (저도 반성합니다.)

저 역시 제가 만든 기존의 코드들을 보니 편의를 위해 사용한 내용들이 많았습니다.

단위 테스트는 내가 만든 서비스의 향상과 기존 테스트를 보고 기존 정책들에 위반하지 않았음을 증명하기 위함이기 때문에 더더욱 잘 만들어야 하는 부분이라고 생각합니다.

최대한 사용을 지양하면서 사용할 수 있도록 실천하겠습니다.

 

좋은자료 : https://blog.10pines.com/2022/05/20/a-quick-guide-to-spring-tests-optimization/