ABOUT ME

개발 지식을 기록, 정리하는 블로그

Today
Yesterday
Total
  • [배달 중계 서비스#3] Spring Cloud 버전 충돌과 Test Context Load 이야기
    개발 일지 2024. 7. 16. 00:38

    기본적으로 자질구레한 에러 해결 과정은 블로그에 업로드 하지 않고 있지만, 하루의 절반 이상을 상실한 허탈감에 이렇게 글을 작성하게 되었다.

    @DataRedisTest를 이용해 테스트를 하던 중에 버전 충돌 발생

    • NoClassDefFoundError: org.springframework.util.SocketUtils

    • util.SocketUtils는 Spring 5.x 시리즈에서 사용되다가 6.x에서 제거된 클래스다.

    • 즉, Spring Boot의 버전과 Spring Cloud의 버전이 맞지 않아 생긴 에러.

    • 현재 사용하고 있는 Spring Boot 3.x.x 버전에선 Spring Cloud를 2023.0.0 이상 사용해야 한다.

    • 동시에 발견한 사실인데, 더 이상 OpenTracing에 Sleuth + Zipkin을 사용하지 않고, Brave + Zipkin으로 구현한다고 한다. 당장은 에러가 안나고 있지만, 이 또한 추후 교체 작업이 필요할 듯.

    • 여전히 남아있는 의문은, 이 오류가 Spring Cloud를 사용하는 테스트에서는 발생하지 않았고, 전혀 상관없는 Redis 테스트에서 발생했다는 것이다.

    • 이전에 작성한 Spring.Cloud.WireMock을 사용하는 테스트는 버전에 관계없이 잘 통과하고 있다.

    Spring Cloud 버전을 최신화 한 이후에 발생한 또 다른 에러다.

    • java.lang.IllegalStateException: Unable to retrieve @EnableAutoConfiguration base packages
    • 스프링 부트의 자동 구성에서 발생하는 에러로, 내가 작성한 테스트 클래스에서 사용한 @DataRedisTest 와 @Import 로 추가한 Context 의외의 의존성을 테스트에서 사용하고 있기 때문인 것 같다.
    • @DataRedisTest 를 @SpringBootTest 로 변경하니 해결은 됐지만, 단일 Repository 클래스를 테스트하기 위해 모든 애플리케이션의 Context를 로드하는 것은 낭비다.

    해결을 위한 조치

    • Spring Cloud 최신화를 통해 버전 충돌을 해결했다.
    • @DataRedisTest와 @Import를 통해 로드하는 Context는 최적화 하면서 모든 에러를 해결할 수 있었다.

    가장 어이가 없었던 Spring Cloud 에러는 여전히 그 트리거와 장애 범위가 불분명하니 조사가 필요할 것 같다.
    그 외에 내가 의도했던 동작에서 발생한 에러는 @DataRedisTest 어노테이션의 적용 범위에 대한 오해가 있었던 것 같다.
    해당 어노테이션의 설명을 보면 Redis에 관련된 Context들을 로드한다고 되어 있어,
    Redis를 사용해 작성한 Config 혹은 Repository 또한 로드할 것이라 생각한 것과는 다르게,
    정말 기본적인 Redis의 의존성만 불러오는 듯 하다.(@DataMongoDBTest는 Repository까지 로드했기에 생긴 오해)
    추가적인 설정 파일이나 Repository는 @Import를 통해 추가하는 것으로 @SpringBootTest를 사용하는 것 보다 압도적으로 높은 최적화를 실현할 수 있었다.

Designed by Tistory.