[테스트] contextLoads() 실패 이유 분석하기

상황

로컬에선 모두 통과하던 테스트가 CI에서 실패했다. 

원인

스택 트레이스를 보니 contextLoads()가 실패했다.

contextLoads()가 무엇인지 잠깐 짚고 넘어가자면, Spring Boot 프로젝트를 만들면 자동으로 생성되는 가장 기본적인 통합 테스트 파일이다. 목적은 Spring ApplicationContext가 정상적으로 로드되는지 확인하는 데 있다. 테스트 메서드 내부는 비어있지만, @SpringBootTest가 붙어 있어서 앱 전체가 실제로 구동되며, 이 과정에서 모든 빈의 생성과 주입이 일어난다. 빈 하나라도 문제가 생기면 컨텍스트 로딩 자체가 실패하는 테스트다.

로컬 환경에선 성공했고 CI에서만 실패한다면, 로컬환경에는 있지만 CI 환경에 없는 빈이 있다는 뜻이다. 에러 스택 트레이스의 말단을 보면 SslHandler.java에서 SslHandshakeTimeoutException이 발생했다고 한다. 이는 Redis에 연결하지 못해서 발생한 에러라고 한다.

로컬에선 docker-compose로 redis가 6379 포트에 띄워져 있다. 하지만 CI 환경에선 기본적으로 Redis가 없다. 따라서 CI 실패를 막기 위해선 1) CI 환경에 Redis 서비스 컨테이너를 추가하거나 2) contextLoads()에서 Redis Bean을 모킹하거나 3) 테스트용 프로파일로 Redis를 비활성화하는 방법이 있다.

AI의 도움을 받아 각 방법마다 장단점을 정리해 보았다.

	방법 1	방법 2	방법 3
	CI에 redis 서비스 추가	@MockBean 처리	테스트 프로파일로 비활성화
핵심 아이디어	CI에서 실제 Redis 컨테이너 실행	Redis Bean을 가짜 객체로 대체	테스트 시 Redis 관련 설정/Bean 자체를 꺼버림
구현 난이도	낮음 (yaml 몇 줄 추가)	낮음 (어노테이션 1줄)	중간 (프로파일 설정 파일 작성 필요)
CI 속도	약간 느려짐 (컨테이너 기동 5~10초)	빠름	빠름
Redis 실제 동작 검증	✅ 가능	❌ 불가 (Mock이라 실제 연결 안 함)	❌ 불가
SSL 이슈 영향	⚠️ 받음 (SSL 설정 분기 필요)	✅ 무관	✅ 무관
다른 통합 테스트와 공유	✅ 다른 테스트도 Redis 사용 가능	❌ 해당 테스트 클래스에만 적용	⚠️ 프로파일 공유 가능하지만 설정 복잡
테스트 목적과의 부합	⚠️ contextLoads의 목적을 넘어섬	✅ Context 구성 검증에 집중	✅ Context 구성 검증에 집중
유지보수	⚠️ 서비스 추가 시 CI yaml도 같이 관리해야 함	✅ 간단	⚠️ 프로파일 관리 부담 생길 수 있음
추천 상황	Redis를 실제로 쓰는 통합 테스트가 다수 존재할 때	contextLoads만 빠르게 고칠 때	테스트 환경을 체계적으로 분리하고 싶을 때

결론적으로, Redis 실제 동작 검증은 로컬에서 충분히 이루어지므로 context 구성 검증에 집중하면서도 유지보수가 간단한 방법2를 구현하기로 했다.

그런데 @MockBean 사용이 안 된다. 공식 가이드를 보니 @MockBean은 Spring Boot 4.x 부터 제거되었고, 이를 대체하는 @MockitoBean도 테스트 클래스 또는 슈퍼클래스에 직접 사용해야 한다고 한다.

그래서 아래처럼 MockitoBean을, 테스트클래스에 적용했다.

결과

CI가 잘 통과했다.