@DataJpaTest를 이용한 테스트 실행 중 발생하는 데이터베이스 및 쿼리 예외 해결

@DataJpaTest를 이용한 Repository 테스트 중 본 어플리케이션 실행에서 발생하지 않던 DDL에서 예외가 발생했다. H2 ↔️ MySQL 문법 차이로 인해 테이블이 제대로 생성되지 않는 것으로 보여서 application-test.properties 를 계속 수정했지만 해결되지 않았다. 문득, 지난 번에도 @DataJpaTest 테스트에서 발생하는 에러를 @AutoConfigureTestDatabase으로 해결한 기억이나서 시도하였고 해결되었다. 그때도 디버깅 과정 기록을 미뤄두고 있었는데, 이 참에 블로깅하고 장기 기억으로 가보자.

---

문제 분석

시도할 때마다 다양한 예외가 발생하고 인터넷에도 다양한 예외 케이스가 있는데, 데이터베이스 설정 문제이거나 DDL 혹은 SQL 문법 오류다. 공통적으로 DataSoruce로 인해 발생한 것인데, 본 어플리케이션은 정상적으로 됬는데, 왜 테스트할 때만 문제가 발생하는걸까? @DataJpaTest를 자세히 살펴보자

• CommandAcceptanceException: Error executing DDL - ... (this database is empty)
• JdbcSQLSyntaxErrorException: Syntax error in SQL statement ... expected "identifier"

/**  
 * Annotation for a JPA test that focuses <strong>only</strong> on JPA components.  
 * <p>  
 * Using this annotation will disable full auto-configuration and instead apply only  
 * configuration relevant to JPA tests. * <p>  
 * By default, tests annotated with {@code @DataJpaTest} are transactional and roll back  
 * at the end of each test. They also use an embedded in-memory database (replacing any * explicit or usually auto-configured DataSource). The * {@link AutoConfigureTestDatabase @AutoConfigureTestDatabase} annotation can be used to  
 * override these settings. * <p>  
 * SQL queries are logged by default by setting the {@code spring.jpa.show-sql} property  
 * to {@code true}. This can be disabled using the {@link DataJpaTest#showSql() showSql}  
 * attribute. * <p>  
 * If you are looking to load your full application configuration, but use an embedded  
 * database, you should consider {@link SpringBootTest @SpringBootTest} combined with  
 * {@link AutoConfigureTestDatabase @AutoConfigureTestDatabase} rather than this  
 * annotation. * <p>  
 * When using JUnit 4, this annotation should be used in combination with  
 * {@code @RunWith(SpringRunner.class)}.  
 * * @author Phillip Webb  
 * @author Artsiom Yudovin  
 * @author Scott Frederick  
 * @since 1.4.0  
 * @see AutoConfigureDataJpa  
 * @see AutoConfigureTestDatabase  
 * @see AutoConfigureTestEntityManager  
 * @see AutoConfigureCache  
 */  
@Target(ElementType.TYPE)  
@Retention(RetentionPolicy.RUNTIME)  
@Documented  
@Inherited  
@BootstrapWith(DataJpaTestContextBootstrapper.class)  
@ExtendWith(SpringExtension.class)  
@OverrideAutoConfiguration(enabled = false)  
@TypeExcludeFilters(DataJpaTypeExcludeFilter.class)  
@Transactional  
@AutoConfigureCache  
@AutoConfigureDataJpa  
@AutoConfigureTestDatabase  
@AutoConfigureTestEntityManager  
@ImportAutoConfiguration  
public @interface DataJpaTest {
    // ...
}

주석에도 잘 설명되어 있는 @DataJpaTest 의 특성은 다음과 같다.

• full application context를 로드하지 않고 JPA 테스트와 관련된 configuration만 활성화하는 테스트 어노테이션
• Repository 계층에 대한 격리된 테슽 환경을 설정하는데 유용
• 임베디드 인메모리 데이터베이스를 사용

어플리케이션 실행할 때도 H2 데이터베이스를 사용하고 있는데, 뭔가 다른걸까? The @AutoConfigureTestDatabase annotation can be used to override these settings. 라고 하니, @AutoConfigureTestDatabase 을 살펴보자.

@Target({ ElementType.TYPE, ElementType.METHOD })  
@Retention(RetentionPolicy.RUNTIME)  
@Documented  
@Inherited  
@ImportAutoConfiguration  
@PropertyMapping("spring.test.database")  
public @interface AutoConfigureTestDatabase {  

    /**  
     * Determines what type of existing DataSource bean can be replaced.     * @return the type of existing DataSource to replace  
     */    @PropertyMapping(skip = SkipPropertyMapping.ON_DEFAULT_VALUE)  
    Replace replace() default Replace.ANY;  

    /**  
     * The type of connection to be established when {@link #replace() replacing} the  
     * DataSource. By default, will attempt to detect the connection based on the     * classpath.     * @return the type of connection to use  
     */    
     EmbeddedDatabaseConnection connection() default EmbeddedDatabaseConnection.NONE;  

    /**  
     * What the test database can replace.     
     * */    
     enum Replace {  

       /**  
        * Replace the DataSource bean whether it was auto-configured or manually defined.        
        * */       
        ANY,  

       /**  
        * Only replace the DataSource if it was auto-configured.        
        * */       
        AUTO_CONFIGURED,  

       /**  
        * Don't replace the application default DataSource.        
        * */       
        NONE  

    }  

}

@PropertyMapping("spring.test.database")을 통해 값을 설정할 수 있지만, application property에서 따로 설정한 값이 없으니 디폴트 설정을 따른다. replace 기본 전략은 ANY는 임베디드 무조건 인메모리 데이터베이스를 DataSource로 설정하고, connection 기본 전략은 NONE이지만 EmbeddedDatabaseConnection, TestDatabaseAutoConfiguration 등을 통해 ClassLoader기반으로 적합한 커넥션을 제공한다. 나의 경우는 H2 커넥션으로 설정되는 것을 로그에서 확인할 수 있었다.

 

---

원인 파악

어? 어플리케이션 환경과 동일한 H2인데 왜 안되지? 라고 생각한다면, 당신은 디버깅 구렁텅이에 빠지게 될 것이다.... 이 설정은 EmbeddedDatabaseConnection에 설정된 기본 H2 url에 랜덤한 유니크 UUID를 데이터베이스 이름으로 자동 생성된 임베디드 인메모리 데이터베이스인데, ;MODE=MYSQL;이 없다!! 초기 어플리케이션 세팅 이후 신경쓰지 않아 까먹었을 텐데, H2와 MySQL은 유사하지만 다른 문법이 존재(특히 DDL)하기 때문에 MySQL 모드로 DataSource를 설정해야만 했다.

public enum EmbeddedDatabaseConnection {  

    /**  
     * No Connection.     
     * */    
     NONE(null),  

    /**  
     * H2 Database Connection.     
     * */    
     H2("jdbc:h2:mem:%s;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE"),  

    /**  
     * Derby Database Connection.     
     * */    
     DERBY("jdbc:derby:memory:%s;create=true"),  

    /**  
     * HSQL Database Connection.     * @since 2.4.0  
     */    
     HSQLDB("org.hsqldb.jdbcDriver", "jdbc:hsqldb:mem:%s");

    // ...
}

---

해결 방안

2가지 방법으로 해결할 수 있는데

1. spring.jpa.properties.hibernate.dialect 을 기본 값 혹은 H2Dialect로 설정한다.
2. AutoConfigureTestDatabase 의 Replace 전략을 NONE으로 설정한다.

처음부터 로컬에서 H2로 쓴 사람이라면 1번을 택하면 되지만, 일반적으로 프로덕션 환경에 맞추기 위해 MySQL 모드로 사용하고 있는 사람도 많을 것이다. 특히 나는 날짜와 관련된 쿼리를 사용했는데, H2와 MySQL에서 지원하는 날짜 함수가 다르기 때문에 1번을 사용할 수 없다. 1번을 사용하면 다음과 같은 에러가 발생한다.

 

따라서 다음과 같이 어노테이션을 통해 Replace 전략을 NONE으로 설정하면, properties에서 설정한 DataSource를 그대로 사용할 수 있다.

@DataJpaTest  
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
@ActiveProfiles("test")  
class MemberPostRepositoryCustomTest {
    // ...
}

---

예외명과 Caused by 절을 통해서는 원인을 알 수 없는 문제였다. 근본적인 문제를 추측하고 구글링과 프레임워크 코드를 분석함으로써 해결할 수 있었는데, 이게 진짜 이상적인 디버깅같아서 뿌듯했다. 블로깅에도 꽤 많은 시간이 들었는데, 결국은 기록이 다 남는 것 같으니 열심하 해봐야겠다.