Embedded Redis JUnit 5 통합 테스트 환경 구축하기(Callback Extension)

배경

저희 모락 프로젝트는 동시성을 제어하기 위해 레디스의 분산락을 사용하였습니다. 분산락을 추가할 때, 로컬에서는 도커를 이용해 레디스 서버를 띄웠고, 운영 서버에서는 레디스 서버가 따로 실행 중입니다. 이에 따라 분산락을 추가할 당시에는 모든 테스트가 실패없이 제대로 동작했으나, 이후 도커를 종료한 뒤 다시 테스트를 실행하니 레디스에 연결하지 못해 @SpringbootTest가 붙은 통합 테스트는 실패하게 되었습니다. 이에 모든 테스트 환경에서 레디스 서버에 독립적일 수 있도록 임베디드 레디스 서버를 테스트에 도입하기로 결정하였습니다.

생각해본 해결 방안

테스트 컨테이너

•

스프링 테스트 시 자체에서 도커를 띄울 수 있기때문에 레디스의 버전, 데몬 등이 어떠한 환경에서건 문제가 없습니다.

•

기본적으로 테스트 환경에 도커가 설치되어 있어야 합니다.

•

또한 도커 컨테이너를 테스트 시에 띄우기 때문에 테스트가 매우 느립니다.

목킹

•

추상화를 해야 하는 부분이 RedissonClient, RLock 두 군데라서 변경점이 많아진다.

•

통합 테스트 시에 분산락을 획득하는 지에 대해 확인할 수 없다.

임베디드 레디스

•

내장 형태로 제공하는 라이브러리가 있어서 어떠한 환경에서든 사용이 가능합니다.

•

또한 통합 테스트 시에도 임베디드 레디스 서버와 실제로 통신이 이루어져 분산락을 획득하는지 확인이 가능합니다.

임베디드 레디스 적용

컨텍스트 빈 라이프 사이클 활용

•

통합 테스트 시에 등록된 모든 빈들을 등록하는데, 이 때 레디스 서버도 임베디드 레디스 서버로 함께 띄울 수 있도록 합니다. 그리고 통합 테스트가 끝나면 임베디드 레디스 서버도 함께 종료합니다.

•

하지만 문제가 있는데요, 통합 테스트가 여러 개일 시에는 포트가 중복되어 다른 서버로 옮겨야 한다는 점입니다. 저희 프로젝트 경우에는 인수 테스트, 애플리케이션 테스트를 위해 @SpringbootTest 가 여러 번 실행됩니다. 이에 따라 포트의 중복이 발생하기때문에 서버를 띄울 때 포트를 확인하고 비어있는 포트로 임베디드 레디스 서버를 띄워야 합니다.

•

이러한 과정은 jojoldu 님의 포스팅에서 잘 나와 있습니다.