[BE] test: 테스트 환경을 MySQL로 통일하기 위해 TestContainers 도입

[donghoony]

• resolves [BE] H2 와 MySQL 의 문법 차이로 인해서 테스트 코드는 통과되지만, 어플리케이션에서는 오류가 발생하는 상황을 해결한다. #757

---

개요 (디스코드에서 이야기한 내용입니다)

지난 데모데이 직전 새벽에 MySQL과 H2의 간극으로 고생했던 기억이 아직 생생한데요.. 이번 기회에 개발 환경에서의 테스트를 H2 -> MySQL로 옮기면 어떨까? 라는 생각을 해봤어요. 물론 이렇게 바로 떠오른 건 아니고, 아래와 같은 생각의 흐름이 있었습니다.

1. Github CI 과정에서 MySQL Container 띄워서 테스트
   이렇게 하면 개발 로컬에서는 H2를 사용하고, PR을 올릴 때 CI 테스트에서는 MySQL를 사용합니다. 다만 이 경우에도 직접 PR을 올리고 테스트를 돌리는 걸 기다리는 데까지 너무 큰 시간이 소요돼요. 로컬 환경과 개발 환경이 서로 다르다는 것이 제일 크기도 하고요.

2. MySQL을 각자의 로컬에 올려두고 테스트
   이건.. 너무 번거롭습니다. 개발하는 사람들마다 직접 MySQL을 깔아줘야 하고, 결국 설정 문제의 차이로 테스트가 갈릴 수도 있는 상황이 발생할 수 있어요.

그래서 찾아보니 TestContainers라는 게 있더라고요. Java 환경에서 Docker를 활용해 테스트용 컨테이너를 띄워주는 건데, 괜찮은가 싶어서 발제해봅니다. 가장 큰 목표는 운영/개발과 로컬의 개발 환경 차이를 최소화하는 것이예요. TestContainers는 MySQL을 비롯해서 Redis와 같은 다른 컨테이너도 지원하기 때문에 추후 개발할 때 테스트에 굉장히 용이할 것이라고 생각했습니다.

단점으로는 아래와 같습니다:

• 각자 Docker를 설치해야 합니다. 다만 이건 따로 설정이 필요한 건 아니고 Docker daemon이 필요한 거라서 추가 설정은 하지 않아도 됩니다.
• 테스트 시간이 늘어납니다. 도커 컨테이너를 실행해줘야 해서 그런데요, 실험해보니 제 로컬에서는 1500ms -> 7740ms로 유의미한 속도 저하가 발생했어요.

🚀 어떤 기능을 구현했나요 ?

• TestContainers를 도입했습니다. 현재 프로젝트에 존재하는 모든 데이터베이스 소통은 컨테이너와 진행합니다.

🔥 어떻게 해결했나요 ?

• 테스트 환경에서의 DataSource를 yml에서 제거하고, TestContainer의 DataSource를 빈으로 등록했습니다.

📝 어떤 부분에 집중해서 리뷰해야 할까요?

• 테스트가 돌아가기 위해서는 도커가 필요합니다. 도커를 설치해 주세요

📚 참고 자료, 할 말

• https://java.testcontainers.org/modules/databases/mysql/
• https://loosie.tistory.com/793
• https://medium.com/riiid-teamblog-kr/testcontainer-%EB%A1%9C-%EB%A9%B1%EB%93%B1%EC%84%B1%EC%9E%88%EB%8A%94-integration-test-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-4a6287551a31

[github-actions]

Test Results

105 tests   105 ✅  14s ⏱️
 38 suites    0 💤
 38 files      0 ❌

Results for commit 6a4813b.

[donghoony]

이전 PR의 테스트에서는 4초정도 걸렸는데 CI 환경에서는 10초 더 걸리네요 🫠

[nayonsoso]

어푸!! 어푸!! 🏊🏻‍♀️

[skylar1220]

다같이 외칩시다
테: 테드
힘: 힘내!

[Kimprodp]

😢😢😂😂 갑시다~~

[donghoony]

• [BE] refactor: NativeQuery를 JPQL로 변환 #808

이 브랜치에서 #808 브랜치 리베이스 후 테스트한 결과 잘 작동합니다 👍🏻 추후 격리를 위해 Draft로 두겠습니다.