Redis testcontainers 제대로 설정하기

[nayonsoso]

문제 상황

ci 설정 중에 ConnectionExeption 예외가 발생했다.

기존 redis 테스트 컨테이너 설정 코드는 다음과 같았다.

@TestConfiguration  
public class RedisTestContainer {  
  
    @Container  
    private static final GenericContainer<?> CONTAINER = new GenericContainer<>("redis:7.0");  
  
    @DynamicPropertySource  
    static void redisProperties(DynamicPropertyRegistry registry) {  
        registry.add("spring.data.redis.host", CONTAINER::getHost);  
        registry.add("spring.data.redis.port", CONTAINER::getFirstMappedPort);  
    }
    
    @PostConstruct  
    void startContainer() {  
        if (!CONTAINER.isRunning()) {  
            CONTAINER.start();  
        }
    }
}

해석하자면,

• static final 변수로 GenericContainer를 만들고
• DynamicPropertySource 어노테이션을 사용해서 테스트 컨테이너로의 연결을 설정하고
• 빈이 생성되고 나서 컨테이너를 실행한다.

라는 내용의 코드이다.

특히나 DynamicPropertySource 을 사용한 이유는,
application.yml 에 설정한 localhost:6379 라는 레디스 설정을 동적으로 덮어씌우기 위함이었다.
test containers가 생성한 도커는 랜덤한 포트로 뜬다.
따라서 랜덤하게 열린 포트로 연결하기 위해서는 동적인 세팅이 필요하다.

---

문제 원인

@TestConfiguration 클래스 안에 @DynamicPropertySource 메서드가 선언된게 문제였다.

애초에 왜 저런 코드를 짰나? 🤔

• @TestConfiguration를 사용한 이유
  • 테스트 컨테이너용 커스텀 어노테이션(TestContainerSpringBootTest)에서 Import 하기 위함이다.
    그럼 커스텀 어노테이션을 사용하는 테스트 클래스들에 대해서, TestConfiguration이 붙은 클래스가 빈으로 등록되어 로드된다.
    이때 설정값이 덮어씌워지길 바랬다.
    • cf. 실제로 MySQL은 이렇게 해서 DataSource 빈을 덮어씌워 테스트 컨테이너를 사용하고 있다.
• @DynamicPropertySource를 사용한 이유
  • 애초에 DynamicPropertySource 자체가 테스트 컨테이너를 위해 만들어진 어노테이션이다.
    

어떤 부분이 잘못되었나? 🤔

@DynamicPropertySource에 대해, 공식 문서에서는 이렇게 말하고 있다.

@DynamicPropertySource is an annotation that can be applied to methods in integration test classes
that need to register dynamic properties to be added to
❗️the set of PropertySources in the Environment for an ApplicationContext❗️ loaded for an integration test.

즉, ApplicationContext의 환경 변수인 PropertySources와 Environment에 값을 동적으로 입력하기 위해 사용되므로,
ApplicationContext가 설정되기 전에 호출되어야 한다.

하지만 @Configuration 어노테이션이 붙은 클래스는 ApplicationContext의 빈으로 등록되는 클래스이다.
따라서 @TestConfiguration 클래스는 ApplicationContext를 설정할 때 로드되므로,
그 클래스 안의 static 인@DynamicPropertySource 메서드는 무의미해진다.
@TestConfiguration클래스가 로드될 때 @DynamicPropertySource 메서드가 호출되어 Environment를 설정하더라도
이미 ApplicationContext를 위한 준비가 완료된 상태이므로 이미 늦었다. 🐢
(디버깅을 해본 결과, @DynamicPropertySource메서드가 실행조차 안된다.)

왜 MySQL의 테스트 컨테이너는 동일한 설정으로도 동작하는가? 🤔

왜 MySQL의 DataSource Bean은 '@TestConfiguration + 커스텀 어노테이션에서 Import' 조합을 썼는데
제대로 테스트 컨테이너 설정이 되고, Redis는 같은 조합을 써도 안되는걸까?

• MySQL은 JDBC로 연결하는 DB이고, Redis는 JDBC를 통하는게 아니라 완전히 외부 서비스라 그렇다.
• MySQL 연결은 DataSource Bean 로 설정된다.
  이 빈을 덮어씌우는 것은 컨텍스트 설정 후에도 가능하다.
• Redis 연결은 환경변수로 설정되므로, 컨텍스트가 설정되기 이전에 설정되어야 한다.

---

문제 해결

테스트 컨테이너를 빈으로 등록하고, 이 빈이 로드될 때 설정을 덮어씌우겠다는 계획은 포기하기로 했다. 🤧
대신 조금 복잡하지만, 일단 통하는 방법으로 진행해보려한다.
바꾼 코드는 다음과 같다.
ref. https://www.baeldung.com/spring-dynamicpropertysource

public class RedisTestContainer implements ApplicationContextInitializer<ConfigurableApplicationContext> {  
  
    private static final int ORIGINAL_PORT = 6379;  
    private static final GenericContainer<?> CONTAINER 
	    = new GenericContainer<>("redis:7.0").withExposedPorts(ORIGINAL_PORT);  
  
    static {  
        CONTAINER.start();  
    }
    
    @Override  
    public void initialize(ConfigurableApplicationContext applicationContext) {  
        TestPropertyValues.of(  
                "spring.data.redis.host="+ CONTAINER.getHost(),  
                "spring.data.redis.port="+ CONTAINER.getMappedPort(ORIGINAL_PORT)
        ).applyTo(applicationContext.getEnvironment());
    }
}

ApplicationContextInitializer 는 ApplicationContext 가 만들어지기 전에 실행되므로,
성공적으로 PropertySources 의 값을 수정할 수 있다.
비록, 테스트 컨테이너를 위해 생겨난 DynamicPropertySource 를 사용하는 방법은 아니지만, 이 방법으로도 동작하긴 한다!

---

느낀 점

Redis 테스트 컨테이너를 제대로 설정하기 위해서 시작한 여정인데,
스프링의 변수 설정 과정에 대해서만 더 깊이 공부하게 됐다. 😗
(사실 테스트 컨테이너 홈페이지에 나와있는 예제를 적용하면 이렇게 깊이까지 할 필요 없는데,
그럼 테스트 클래스마다 테스트 컨테이너를 설정해줘야해서 중복코드가 너무 생긴다고 생각했다.)
다른 개발자들은 테스트 컨테이너 레디스가 필요할 때, 매번 테스트 코드에서 생성하는걸까?
조금 더 많은 경험을 하면 더 좋은 코드를 작성할 수 있을것 같다!

[Gyuhyeok99]

제가 이 부분에 깊게 이해하고있지 않았는데 글과 공식문서를 같이 읽어보니 @TestContainerSpringBootTest 어노테이션을 활용하는 방안중에 최선이었던 거 같아요!

사실 테스트 컨테이너 홈페이지에 나와있는 예제를 적용하면 이렇게 깊이까지 할 필요 없는데,
그럼 테스트 클래스마다 테스트 컨테이너를 설정해줘야해서 중복코드가 너무 생긴다고 생각했다.

이거에 대해서는 궁금하긴 하네요. 각 테스트 클래스마다 저걸 선언하진 않을 거 같고 abstract로 @DynamicPropertySource 관련 설정 파일을 해놓고 각 클래스마다 상속받는 방식도 될 거 같긴 한데 해결책은 아닌 거 같네요. 😅

좋은 글 감사합니다!