서비스 테스트 개선하기

기존의 서비스 코드

@DataJpaTest
@Import(ReservationConfig.class)
class ReservationApplicationServiceTest {

		// ... 필요한 주입 및 테스트 ...

    static class ReservationConfig {

        // @Bean
        // ... 필요한 실제 객체 주입 ...
    }
}

 

문제점

1. @DataJpaTest를 사용하고 있다.

일반적으로 @DataJpaTest 는 일반적으로 Repository 테스트를 위한 것이다! 게다가 Service 테스트에서 조심하게 사용해야 하는 @Transactional 애노테이션이 기본적으로 붙어있다. 그렇기에 다른 방법을 찾아야 한다.

 

2. inner class로 ReservationConfig를 통해 빈을 직접 등록하고 있다.

수 많은 연관관계를 어떻게 다 기억하지?

 

이렇게까지 빈을 등록하며 서비스를 테스트 하는 것은 원치 않는다.

 

개선해보자.

먼저 @DataJpaTest 애노테이션을 제거해보자.

 

스프링에는 @WebMvcTest, @EnableJpaRepositories 등… 많은 애노테이션이 있다. 하지만, 서비스 테스트를 위해서는 Jpa 관련 빈과 Service, Repository 구현체에 대한 빈들도 필요하다. 위의 애노테이션들을 활용한다고 해도 단편적으로 빈을 등록한다. 그래서 결국 이전처럼 빈을 등록해주는 Config inner class를 만들어야 한다. 그러면 스프링 컨텍스트를 만들고 전체적으로 빈을 만들어주는 애노테이션을 활용할 수 밖에 없지 않을까? 그 역할을 하는 애노테이션이 바로 @SpringBootTest 이다.

 

하지만 @SpringBootTest 를 그대로 사용하기엔 너무나도 느리다. 그리고 서비스 계층을 넘어 컨트롤러와 기타 웹 관련 빈들도 생성하기에 통합 테스트에서나 활용할 수 있지, 서비스의 단위 테스트에는 적합하지 않다. 그래서 이를 어느정도 제한하는 옵션을 활용했다.

 

바로 webEnvironment = SpringBootTest.WebEnvironment.NONE 이다. 이 옵션을 넣으면 이전처럼 스프링 컨텍스트를 만들고 빈들을 생성하지만 그 이상의 웹 요청/응답 흐름의 관련 빈들은 생성하지 않는다. 즉, 디스패처 서블릿, 리졸버, 핸들러 등의 빈이 생성되지 않는다! 서비스 테스트에 적합한 것 같다. 코드로 표현한다면 다음처럼 될 것이다.

 

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.NONE)
class ReservationApplicationServiceTest {

		// ... 필요한 주입 및 테스트 ...
}

 

이로써 문제점 1번과 2번을 모두 해결했다. 하지만, 간과한 것이 하나 있다. 바로 공유 의존성이다.

 

공유 의존성은 테스트 간에 서로 공유되는 의존성으로 하나의 테스트에서 수행한 결과가 다른 테스트에도 영향을 미치는 것이다. 대표적으로 데이터베이스가 있다. @DataJpaTest를 사용했을 때는 내부에 @Transactional이 있었기 때문에 테스트마다 롤백되어 DB가 공유 의존성이 아니게 되었지만 지금의 해결방식은 내부적으로나 외부적으로 @Transactional이 없어서 공유 의존성이 되었다.

 

그렇다고 서비스 테스트에 @Transactional을 붙이는 것은 위험하다. 왜냐면, 서비스 로직 상 트랜잭션을 의도하지 않았음에도 테스트에는 트랜잭션이 붙기 때문에 테스트가 거짓 양성이 될 확률이 높아지기 때문이다. 그렇다면 사실 방법은 하나 뿐이다. 바로 직접 DB를 롤백하는 것!!

 

@SpringBootTest(webEnvironment = WebEnvironment.NONE)
public abstract class BaseServiceTest {

    @Autowired
    private DatabaseCleaner databaseCleaner;

    @BeforeEach
    void setUp() {
        databaseCleaner.clean();
    }
}

@Component
public class DatabaseCleaner {

    private static final String FOREIGN_KEY_SET_ON = "SET REFERENTIAL_INTEGRITY TRUE";
    private static final String FOREIGN_KEY_SET_OFF = "SET REFERENTIAL_INTEGRITY FALSE";
    private static final String TRUNCATE_TABLE_QUERY = "TRUNCATE TABLE %s RESTART IDENTITY";

    @PersistenceContext
    private EntityManager entityManager;
    private List<String> tableNames;

    @PostConstruct
    void setTableNames() {
        tableNames = entityManager.getMetamodel().getEntities().stream()
            .filter(entityType -> entityType.getJavaType().getAnnotation(Entity.class) != null)
            .map(entityType -> CaseFormat.convertCamelToSnake(entityType.getName()).toLowerCase())
            .filter(tableName -> !(tableName.equals("member") || tableName.equals("admin")))
            .toList();
    }

    @Transactional
    void clean() {
        entityManager.createNativeQuery(FOREIGN_KEY_SET_OFF).executeUpdate();
        for (String tableName : tableNames) {
            entityManager.createNativeQuery(String.format(TRUNCATE_TABLE_QUERY, tableName)).executeUpdate();
        }
        entityManager.createNativeQuery(FOREIGN_KEY_SET_ON).executeUpdate();

        entityManager.flush();
        entityManager.clear();
    }
}

 

결과부터 보자면 나는 이렇게 테스트 코드를 개선했다. 모든 서비스 테스트가 테스트 메서드가 시작하기 전 @BeforeEach로 DB를 롤백시킬테고, @SpringBootTest(webEnvironment = WebEnvironment.NONE) 애노테이션이 붙을테니까 이를 하나의 클래스로 묶어줬다. 그리고, 서비스 테스트가 이를 상속하는 방법으로 구현했다.

 

이로써 서비스 테스트는 BaseServiceTest만 상속 받으면 지저분한 Config 파일이 필요없다는 점과 @DataJpaTest 애노테이션 제거를 이뤄낼 수 있다.

 

@DataJpaTest

@SpringBootTest

 

아쉽게도 시간 자체는 좀 늘어났지만, 서비스 테스트라는 목적성을 달성할 수 있었으니 의미있는 개선이라고 생각한다.