🏡

테스트 환경 개선기

생성일

2022/10/23

태그

Spring

test

배경

원인 파악

Application Context Caching

배경

저희는 프로젝트 초기부터 테스트 속도를 높이기 위해 신경을 썼습니다. 대표적으로 테스트 데이터를 격리하기 위해 @DirtiesContext 를 사용하지 않고, sql script 를 이용하였습니다. 또한 서비스 계층에서 불필요한 @SpringBootTest 대신 @DataJpaTest 와 @Import 만으로 서비스 계층 테스트를 수행할 수 있도록 하였습니다.

하지만 프로젝트가 점점 커지고 테스트 케이스 수가 400개를 넘어가면서, 테스트를 수행하는 데에 걸리는 시간이 점점 오래 걸리게 되었습니다. 소요되는 시간이 점진적으로 늘어났기때문에 인지하기 힘들었는데, 한번은 테스트를 돌리고 화장실을 다녀왔는데도 전체 테스트가 계속 수행중이었던 것을 보고 ‘이거 너무 오래 걸리는데’를 깨닫게 되었습니다..

현재 기준으로 찍히는 시간은 51초 정도 되지만 실제 추산되지 않은 시간까지 합하면 체감 시간은 2분 정도 걸리는 것 같습니다. 팀원들도 동일한 문제를 인식하고 있었기때문에 테스트 속도를 개선하기로 결정했습니다.

원인 파악

먼저 어디서 오래 걸리는지 파악하는 것이 중요했습니다. 저희 테스트는 크게 총 5가지 인수 테스트, 컨트롤러 테스트, 서비스 테스트, 레포지토리 테스트, 도메인 단위 테스트로 구분할 수 있습니다. 도메인 단위 테스트는 단순히 컴파일만 되면 수행할 수 있지만 나머지 4가지의 테스트는 컨텍스트 빈을 띄워야 합니다. 이 중 인수 테스트 는 @SpringBootTest를 사용하고, 컨트롤러 테스트는 @WebMvcTest, 서비스 테스트와 레포지토리 테스트는 @DataJpaTest 를 사용하여 컨텍스트 빈들을 띄웁니다. 그리고 이 컨텍스트 빈을 띄우는 과정에서 시간이 소요될 것이라고 판단하였습니다. 실제로 테스트가 수행되는 창을 보고 있으면 도메인 단위 테스트 부분은 ‘진짜 테스트를 한건가’ 싶을 정도로 순식간에 지나가지만, 나머지 테스트들은 ‘아 지금 이 테스트를 수행하는 중이구나’ 라는 생각이 들 정도로 버퍼링이 있었습니다.

Application Context Caching

테스트가 수행되는 걸 보는데 이상한 점이 발견되었습니다. SpringBoot 가 재실행되는 빈도가 너무 높았습니다.

@DirtiesContext 를 사용하지 않은 이유가 테스트 환경 초기화(정확히는 in-memory DB 초기화)를 테스트마다 매번 하지 않고 Application Context 를 재활용하기 위해서였는데, Application Context 를 재활용하지 않고 SpringBoot 가 계속 재실행되는 것이었습니다.

이유는 Application Context Caching 의 재활용 조건에 있었습니다. Application Context Caching 이 재활용되지 않고 새로 띄우는 조건은

등록된 빈들 중 빈의 내부에서 오염이 되었을 때(빈의 내부 필드가 변경되었을 때)

Context 내부 등록된 빈의 내용이 다를 때(빈 추가 또는 제거)

등이 있는데, 2번에서 문제가 발생하였습니다. 2번은 쉽게 말해서 Context Bean 들의 스냅샷을 뜨고, 이후 테스트에서 Context Bean 의 내용이 스냅샷과 다르면 Caching 을 사용하지 않고 다시 초기화시키는 것입니다. 저희가 작성한 @WebMvcTest 의 내용은 간단히 다음과 같습니다.

@MockBean(RoleService.class)
@WebMvcTest(RoleController.class)
class RoleControllerTest {
}

@MockBean(AppointmentService.class)
@WebMvcTest(AppointmentController.class)
class AppointmentControllerTest {
}
Java
복사

RoleControllerTest 를 수행할 때에는 @WebMvcTest 와 관련된 빈, RoleService, RoleController 가 Application Context 의 빈으로 등록되고, AppointmentControllerTest 를 수행할 때에는 @WebMvcTest 와 관련된 빈, AppointmentService, AppointmentController 가 빈으로 등록이 됩니다. 이에 따라 캐싱의 조건을 위배하게 되고, 컨텍스트 빈을 새로 띄우게 되는 것이었습니다.

이러한 문제는 컨트롤러 테스트 뿐만 아니라 서비스 테스트에서도 발견되었습니다.

@DataJpaTest
@Import(PollService.class)
@Sql(scripts = {"classpath:schema.sql", "classpath:data.sql"})
class PollServiceTest {

    private final MemberRepository memberRepository;
    private final TeamRepository teamRepository;
    private final TeamMemberRepository teamMemberRepository;

    private final PollService pollService;

    @Autowired
    public PollServiceTest(
            MemberRepository memberRepository,
            TeamRepository teamRepository,
            TeamMemberRepository teamMemberRepository,
            PollService pollService
    ) {
        this.memberRepository = memberRepository;
        this.teamRepository = teamRepository;
        this.teamMemberRepository = teamMemberRepository;
        this.pollService = pollService;
    }
}
Java
복사

ServiceTest 는 위와 같이 구성되어있고, 각각의 ServiceTest 를 수행할 때마다 @DataJpaTest 와 관련된 빈, @Import 로 등록하는 각각의 Service 가 빈으로 등록이 됩니다. 이에 따라 매 서비스 테스트 클래스마다 Application Context 를 초기화시켰습니다.

SpringBoot 가 얼마나 많이 실행되는지 실제로 세어보았습니다.

•

appointment, auth, poll, role, team 등 5개 도메인의 서비스 테스트, 컨트롤러 테스트 에서 10번

•

core 1개 도메인에서 서비스 테스트, 두개의 컨트롤러 테스트 총 3번

•

notification 1개 도메인에서 두 개의 서비스 테스트 총 2번

•

인수테스트, ApplicationTest 를 위한 @SpringBootTest 에서 총 1번

•

레포지토리 테스트를 위한 @DataJpaTest 에서 총 1번

전체 테스트를 한번 돌리면 총 17번 Application Context 가 초기화되고 있었습니다

해결 - 동일한 환경을 만들자!

같은 성격의 테스트마다, 같은 Application Context Bean 환경을 만들어주면 Caching 이 되어 초기화하기 위한 SpringBoot 재실행을 하지 않을 것이라고 생각하였습니다.

1. 모두 SpringBootTest 로 하자!

가장 처음 생각한 방법은 모든 빈들을 띄워 SpringBoot 를 한번만 실행시키는 것이었습니다. 하지만 이 방법은 단순히 SpringBoot 를 한번만 실행시키는 것 뿐이지, 각각의 테스트 성격에 맞지 않는 방법이었습니다. 매번 전체 테스트만 돌리진 않을 것이고, 테스트 클래스만 단독으로 돌리는 일도 많은데 불필요한 빈들이 등록되어 있기때문에 전체적인 테스트 맥락을 보면 어울리지 않는 해결책이었습니다.

2. 유사한 성격의 빈들을 한번에 등록하자!

유심히 보면 해당 문제는 컨트롤러 테스트와 서비스 테스트에서 발생하는 문제입니다. 컨트롤러 테스트에서는 각각 도메인의 컨트롤러와 모킹을 위한 서비스 클래스만 빈으로 등록이 되면 테스트 수행이 가능하고, 서비스 테스트는 서비스 클래스만 빈으로 등록이 되면 테스트 수행이 가능합니다.

이에 따라 추상화를 한단계 높이고 추가되는 클래스만 한번에 빈으로 등록하는 방법을 생각했습니다.

@WebMvcTest({
        GlobalController.class,
        OAuthController.class,
        TeamController.class,
        PollController.class,
        AppointmentController.class,
        RoleController.class,
        NotificationController.class,
})
@MockBean({
        OAuthService.class,
        TeamService.class,
        AppointmentService.class,
        PollService.class,
        RoleService.class,
        WebhookService.class
})
public abstract class ControllerTest {
}
Java
복사

다음과 같이 상속할 추상 클래스를 하나 만들고, 해당 클래스에서 컨트롤러와 서비스 클래스들을 모두 한번에 등록시켰습니다. 이러한 방식으로 세 가지의 장점을 얻을 수 있었습니다.

각각의 도메인에서 컨트롤러 테스트를 수행할 때 관련된 모든 빈들이 등록되어 추가, 변경되는 빈들이 없기때문에 동일한 컨텍스트 빈 환경을 만들 수 있다. 

컨트롤러 테스트에서 공통으로 수행되던 인증 관련 로직(JwtProvider)을 만들어 중복되는 메서드도 제거할 수 있다.

새로운 도메인에 대한 컨트롤러 테스트를 추가할 때에도, 해당 컨트롤러를 어노테이션에 추가만 하면 되어 확장 측면에서 관리가 용이하다.

그리고 각각의 컨트롤러 테스트에서 붙어있던 어노테이션을 지우고 ControllerTest 를 상속받았습니다.

class RoleControllerTest extends ControllerTest {
}
Java
복사

서비스 테스트도 유사하지만 다른 방식으로 변경하였습니다. 하지만 각각의 서비스에서 공통되는 로직이 없었기때문에 굳이 클래스로 상속하지 않고 커스텀 어노테이션을 구현하였습니다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@DataJpaTest(includeFilters = @Filter(classes = {Service.class, FakeBean.class}))
@Sql(scripts = {"classpath:schema.sql", "classpath:data.sql"})
public @interface ServiceTest {
}
Java
복사

includeFilters 옵션을 통해 빈으로 등록할 클래스를 추가할 수 있습니다. 해당 어노테이션에서는 서비스 어노테이션이 붙은 클래스를 빈으로 등록시켰습니다. FakeBean 은 Slack 등과 같은 외부 API 로직을 위해 사용한 커스텀 어노테이션이고, 서비스 테스트시 사용되어 함께 추가하였습니다.

이와 같은 어노테이션 방식은 새로운 도메인에 대한 서비스가 추가되어도, 해당 서비스 클래스를 따로 테스트 클래스에서 추가할 필요없이 includeFilters 를 통해 등록되기때문에 컨트롤러 테스트 방식보다 확장에 더욱 용이하다는 장점이 있습니다.

Application Context 환경을 위와 같이 변경하고 다시 SpringBoot 재실행 횟수를 세어보니 5번으로 줄었습니다. @SpringBootTest, @DataJpaTest, 컨트롤러 테스트, 서비스 테스트에서 한 번씩 총 4번 재실행되었고, @ActiveProfiles(”master”) 어노테이션이 붙은 PollSchedulerTest 에서 재실행을 한번 더 하였습니다. 관련 레퍼런스를 보면 active profile 이 다른 경우에도 재활용하지 않고 새로 컨텍스트 빈을 띄운다고 합니다.

수행 시간이 크게 줄지는 않았지만 Application Context 를 초기화하기 위해 뚝뚝 끊기던 작업이 17회에서 5회로 줄었고, 추산되지 않은 체감상 시간도 많이 줄었습니다.

초기화되는 카운트 옵션 추가

직접 세는 방법 이외에도 springframework 의 옵션을 이용하여 컨텍스트 빈이 재활용되는 수를 카운팅할 수 있습니다.

logging:
  level:
    org:
      springframework:
        test.context.cache: DEBUG
YAML
복사

springframework 의 ContextCache 는 앞서 이용한 Application Context Caching 을 테스트에서 지원해주는 인터페이스입니다. 해당 클래스의 로깅 옵션을 DEBUG로 설정하면 logStatistics 메서드를 이용하여 통계를 확인할 수 있습니다.

[2022-10-22 15:26:51:34733][main] DEBUG o.springframework.test.context.cache - Spring test ApplicationContext cache statistics: [DefaultContextCache@436867c3 size = 5, maxSize = 32, parentContextCount = 0, hitCount = 1384, missCount = 5]
Plain Text
복사

missCount 를 확인하여 Context caching 을 하지 못하고 초기화한 횟수를 확인할 수 있습니다.

build 방식 변경

코드를 수정하는 방법 이외에 build 를 하는 방식에서도 속도의 차이가 있다는 말을 듣고 이에 관해 찾아보았습니다. build 자동화 도구 중에는 gradle 이외에도 IntelliJ 도 있습니다. gradle 은 오픈 소스 빌드 자동화 도구이고 IntelliJ 의 build 는 IntelliJ 자체에서 제공하는 빌드 자동화 도구입니다.

두 도구는 build 방식에서 차이가 있는데, 가장 큰 차이점은 IntelliJ build 에서 제공하는 Incremental Build 입니다. 이 방식은 코드가 최신이라고 판단하면 건너뛰고, 추가/변경된 부분 등 추가적인 부분에 대해서만 다시 build 를 진행합니다. 이로 인해 build 속도가 빠르다는 장점이 있지만 지원하지 않는 의존성이 있을 수도 있다는 단점이 있습니다.

Run tests using 을 Gradle (Default) 에서 IntelliJ IDEA 로 변경한 뒤 속도를 측정해 보았습니다.

빌드 방식을 변경하여, 42초에서 24초로 눈에 띄는 속도 변화를 체감할 수 있었습니다.

주의점

Build and run using 까지 바꾸지 않은 이유는 앞서 언급한 단점때문입니다. 추가적인 코드 변경 부분에 대해서만 빌드를 수행하고, 지원하지 않는 의존성이 있을 수 있는 단점이 있는데, 저희 프로젝트에서 이 상황을 마주하였습니다.

저희는 쿼리 성능 측정을 위해 테스트에서 dummy 데이터를 넣어주는 작업을 하고 있고, 이 작업을 위해 lombok 을 사용하였습니다. 그리고 test 에서도 lombok 을 쓸 수 있도록 하기 위해 build.gradle 파일에 다음과 같이 의존성을 추가하였습니다.

testCompileOnly 'org.projectlombok:lombok:1.18.12' 
testAnnotationProcessor 'org.projectlombok:lombok:1.18.12' 
Groovy
복사

그리고 Build and run using 을 IntelliJ IDEA 로 설정하고 test 를 돌리면 다음과 같은 에러가 발생합니다.

lombok 에서 지원하는 컴파일러가 아니라는 에러 내용입니다. 이에 따라 의존성에 관한 compile 은 기존의 Gradle 에 맡겨두고 test 를 할 때만 IntelliJ build 방식을 이용할 수 있도록 위와 같이 설정하였습니다.

참고

•

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/context/cache/ContextCache.html

•

https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#testcontext-ctx-management-caching