테스트를 위한 embedded 레디스 서버를 실행한다.

[leo0842]

상세 내용

Close #620

문제점

• 레디스 서버가 테스트 환경 시에 떠있지 않으면 커넥션 에러가 발생하였습니다.
• 모든 테스트 환경에서 테스트가 통과할 수 있도록 레디스 서버에 독립적인 테스트 환경을 만들어야 합니다.

고려해본 사항

• 스프링 도커로 레디스 서버 띄우기

  • 이 방식은 스프링 도커로 레디스 서버를 띄우고 해당 서버로 커넥션을 연결하는 방식입니다.
  • 스프링 도커로 레디스 서버를 실행시키는 시간이 오래 걸리는 문제점과 스프링 도커가 테스트하는 환경의 운영체제에 다소 의존적인 경향이 있어 보류하였습니다.

• 레디스 관련 클래스 모킹하기

  • 현재 사용하는 RedissonClient 를 모킹하면 해당 구현체가 연결을 시도하던 로직이 실행되지 않아 연결을 하지 않고 테스트를 통과할 수 있습니다.
  • 하지만 통합 테스트 시에 레디스 분산락 관련 로직이 수행되어 단순한 모킹으로는 해결할 수 없습니다.
  • 그래서 목 객체를 만들고자 하였지만 구현해야 하는 메서드가 너무 많아 보류하였습니다.

-> 이에 따라 임베디드 레디스 서버 의존성을 추가하여 사용하였습니다. 임베디드 레디스 서버를 활용하는 방법은 두 가지가 있습니다.

• 가장 널리 알려진 빈 등록 시에 @ PostConstruct 와 @PreDestroy 를 활용하여 임베디드 레디스 서버를 구축하는 방식입니다(관련 jojoldu님 포스팅).

  • 해당 방식은 단일 스프링부트테스트에서는 활용도가 높지만 스프링부트테스트가 여러 개일 때에는 포스팅에 나온 것과 같이 포트 충돌이 발생하여 포트를 확인하고 비어있는 포트로 띄워줘야 하는 불편함이 있습니다(아마 레디스 서버를 내리는 중에 새로운 레디스 서버를 띄우려고 시도해서 포트 충돌이 일어나는 것 같습니다).
  • 또한 포트를 확인하고 비어있는 포트를 확인하는 과정에서 명령어를 수행하기때문에 위험할 수도 있다고 판단하였습니다.

• 결론적으로 Junit5 의 Callback 을 활용하여 해결하였습니다.

  • 모든 테스트를 실행할 시에도 한번만 임베디드 레디스 서버를 띄우기 때문에 포트충돌할 가능성이 없습니다.
  • 또한 코드가 직관적이기때문에 유지/보수에도 효율적이라고 판단합니다.
  • 생각해본 문제점은 두 가지가 있는데, 하나는 외부 의존성을 사용해서 신뢰도가 다소 떨어질 수 있다는 부분이 있고, 두번째로는 스프링부트테스트를 추가할 때마다 익스텐션을 추가해야 한다는 점입니다.

[leo0842]

수고하셨습니다~ 몇 가지 보면서 궁금한 점이 생겼는데, 답변 부탁드리겠습니다 👍

스프링 도커로 레디스 서버를 실행시키는 시간이 오래 걸리는 문제점과 스프링 도커가 테스트하는 환경의 하드웨어에 다소 의존적인 경향이 있어 보류하였습니다.

제가 잘 이해가 안되서 그런데, 어떤 점에서 하드웨어에 의존적인 경향이 있는건가요 ? 제가 레디스를 잘 안써봐서 그런거기도 한데 ㅋㅋ 레디스가 하드웨어 아키텍쳐에 영향을 받기도 하나요 ?

아 제가 단어 선택을 잘못한 것 같습니다 😭 여기서 말씀드린 스프링 도커 는 테스트 컨테이너 를 말씀드린 거였습니다. 스프링에서 제공하는 테스트 컨테이너는 테스트에서 도커 이미지를 사용할 수 있는 라이브러리인데, 이 테스트 컨테이너는 기본적으로 도커가 설치되어 있어야 사용이 가능하고 도커와의 버전, 해당 테스트 환경의 운영체제에도 영향을 받는 것으로 알고있습니다!

생각해본 문제점은 두 가지가 있는데, 하나는 외부 의존성을 사용해서 신뢰도가 다소 떨어질 수 있다는 부분이 있고, 두번째로는 스프링부트테스트를 추가할 때마다 익스텐션을 추가해야 한다는 점입니다.

외부 의존성이라고 하면 혹시 junit 에 대한 의존성을 말하시는걸까요 ? 그리고 스프링부트 테스트를 추가할때마다 extension 을 추가해야 한다는 말이 잘 이해가 안되서요. @AcceptanceTest 가 아닌 @SpringBootTest를 사용하거나, 혹은 새로 정의하는 @MyNewSpringBootTest 를 추가해서 사용할 때 레디스 callback extension 을 추가해야 한다는 말씀이실까요 ?

외부 의존성은 해당 임베디드 레디스 서버를 제공하는 ozimov 의 레포지토리에 의존한다는 의미입니다. 해당 레포지토리는 2020년 6월 11일 이후로는 머지가 없기도 하고 현재까지 코드에 문제가 없더라도 레포지토리가 없어지면 사용할 수 없기때문에 외부 의존성이라고 하였습니다!

스프링부트 테스트를 추가할 때마다 extension 을 추가해야 한다는 말은 후자인 @SpringBootTest를 사용하거나, 혹은 새로 정의하는 @MyNewSpringBootTest 를 추가해서 사용할 때 가 맞습니다. 통합 테스트 이외에도 스프링부트테스트가 추가될 수도 있고, 단순히 해당 익스텐션만 추가해서 테스트할 수 있기도 하여 관리 포인트가 늘어날 수 있다는 생각을 하였습니다. 왜냐하면 테스트를 돌리는 모든 환경에서 레디스가 떠있다면 굳이 해당 익스텐션이 필요가 없으니까요!

• 추가로 생각난건데, 저희가 H2 대신에 docker 로 mysql 을 띄웠던 이유는 인덱스나 트랜잭션, 그리고 이에 동반되는 동시성문제와 같이 밴더사마다 다른 경우를 테스트할 필요가 생겨서인데요. 레디스도 단순 캐시를 저장/조회하는 로직을 목적으로만 사용한게 아니라, 마찬가지로 동시성에 민감한 문제를 해결하기 위해서 사용한건데, embedded 로 띄워야하는 이유가 있을까요? mysql 과 같이 docker 로 띄우지 않고 embedded 로 사용한 이유가 있을까요 ?

이 역시 도커가 설치되어 있다는 것과 레디스 서버가 띄워져 있다는 것이 전제되어야 합니다! 지금 경우도 레디스 분산락 로직을 추가할 때 함께 추가하지 못하고 지금 하는 이유가 레디스 분산락 로직을 추가할 때에는 도커로 레디스 서버를 띄운 상태로 테스트하여 문제가 없었지만, 이후 서버를 내리고 테스트를 돌려본 뒤 발견한 예외입니다. 만약 도커가 설치되어 있지 않다면, 또한 도커로 서버를 띄우지 않았다면 테스트가 실패하기에 따로 서버를 띄우지 않고도 독립적인 테스트 환경을 만들기 위해 임베디드를 사용하였습니다!