@EnableJpaAuditing을 분리하자 !

👀 문제상황

mongoDB를 사용하는 도메인의 repository layer의 단위테스트를 하기 위해 테스트 코드를 짜려고 하는 상황이었다.

 

@DataMongoTest 어노테이션을 붙이고 테스트 코드를 짜고 확인하려고 했는데 자꾸 에러가 떠서 테스트에 실패를 했다. 이 문제를 해결하기 위해 로그를 보니 다음과 같은 로그가 찍혀있었다.

 

 나는 @DataJpaTest를 올린적이 없는데 왜 JPA metamodel을 요구하는 거지? 라고 생각했다.

 

그래서 프로젝트를 만지작 하기도 하고 블로그 글도 찾아보고 열심히 구글링 해보면서 왜 그런지 이유를 알게 되었다.

 

@EnableJpaAuditing

기본적으로 Entity에 생성일자, 수정일자 등의 필드에 값을 넣으려면 LocalDate 클래스로 직접 넣어주는 방식으로 구현을 한다.

 

하지만 해당 어노테이션을 사용하면 따로 넣어주지 않고 @CreatedDate, @LastModifiedDate어노테이션 선언만 하면 생성될 때나 수정 되는 경우에 자동으로 값을 넣어준다. 그리고 많이 사용하는 방법으로 공통 클래스 BaseTimeEntity를 만들어 관리하곤 한다.

 

@DataMongoTest

물론 나는 MongoDB를 사용하는 중이기 때문에 테스트를 위해 해당 어노테이션을 사용했지만 @DataJpaTest도 동일하다.

 

해당 어노테이션을 사용하게 되면 @SpringBootTest와는 달리 빠른 테스트를 위해서 Bean 전부를 로드하지 않고 필요한 Bean들만 컨텍스트에 로드하게 된다.

 

그러면서 JPA Auditing 과 관련된 빈들은 올라오지 않게되는데 문제는 Application을 실행하면서 @EnableJpaAuditing이 선언되어 있기 때문에 Jpa Auditing 관련 빈들을 기대하게 된다.  하지만 해당 Bean들은 로드되지 않았기 때문에 에러를 발생시키게 되는 것이다.

 

분리

간단한 방법으로는 @MockBean을 통해서 JpaMetaModelMappingContext를 Mock 처리 하는 것이다.

 

하지만 모든 테스트에 다는 것 보다 분리를 통해서 Jpa 관련 테스트를 할 때만 로드되도록 하는게 유지보수 측면에서 나을 것이라고 생각했다. 

 

그래서 Config 클래스를 생성해서 해당 설정 클래스에 달아주면 Jpa와 관련된 테스트를 할 때만 @EnableJpaAuditing가 실행될테고 다른 테스트는 분리할 수 있게된다. 

 

왠만하면 Main Application에 설정 어노테이션을 다는 것 보다 설정 클래스를 분리해서 책임을 분리하는 것이 낫겠다는 생각이 들었다.