TestContiners를 왜 썼는가

Why?

테스트 코드를 작성하고, 프로젝트를 완성해 나가면서 항상 테스트 환경에 대한 고민을 하게 되었다. 대표적으로 Repository는 어디를 붙어야 할지.. 또 특정 서버와 연결을 해두었다면 (test 서버), 해당 DB의 데이터를 비워주거나 누적되지 않게 따로 관리를 해야 할지...

-> 멱등성이 깨지는 것에 대해 계속 신경이 쓰였다.

 

in-memory DB를 사용해도 좋지만, 이 경우 운영환경에서 예상하지 못한 예외가 발생할 수 있다. 지난 프로젝트에서는 H2 DB로 테스트를 하다가 운영배포를 할 때 예약어로 인한 문제가 발생했다. (user, row, column) - MySQL 예약어 목록

 

때문에 운영환경과 최대한 유사하게 테스트 환경을 구축하고자 했다. 처음에는 Docker-Compose를 이용해 필요한 서비스(mysql, rdis)를 하나의 컨테이너로 실행하여 수행했다. Docker-Compose 파일을 공유해 모든 팀원이 Docker Engine만 있다면 로컬 테스트 환경을 어렵지 않게 구축할 수 있었다. 또한 Github Actions를 통해 CI를 적용할 때도 Docker-Compose를 실행하는 Step을 추가하여 지속적인 통합도 가능했다.

 

하지만 아쉬운 점도 있었다. 로컬에서 Build를 위해서는 컨테이너가 반드시 실행되어있어야 한다는 점과 CI과정에서 Docker-Compose를 실행해야 한다는 점이 Docker에 너무 의존적이라는 생각이 들었다. 또한 이 경우도 ddl-auto를 create-drop과 같이 설정하지 않는다면 남아있는 데이터를 관리해주어야 했다. 그렇다 보니 local 테스트에 불편함이 있었다. (인증로직을 위해 계속 회원가입 API로 새로운 계정을 만들어야 하는 등..)

 

local테스트를 위한 컨테이너와, test 실행을 위한 컨테이너를 따로 두어도 되지만, docker에 의존적이라는 문제를 해결할 수는 없었다.

 

TestContainers?

내가 느낀 불편함들을 TestContainers를 통해 해결할 수 있었다. 기존 방식들의 문제점과 TestContainers에 대한 설명은 아래 블로그를 참조했다.

 

- 딜리셔스 기술 블로그

- Ref2

 

실제 구현 과정에서는 공식문서의 도움을 따랐다.

- TestContainers for Java

 

간단히 정리하면 도커 이미지를 다운로드하고, 컨테이너를 실행하고, 종료하는 과정을 자바 코드로 정의할 수 있다. 실행에 필요한 도커 요구사항만 충족됐다면, 자바 설정파일을 통해 어디서든 테스트할 수 있다.

 

결론

테스트 컨테이너를 사용하면 멱등성을 지킬수 있고, 컨테이너에 대한 관리를 쉽게 할 수 있다. (port, 실행 및 종료 등등)