로컬 환경에서 통합 테스트할 때 매번 서버를 올리는 일이 매우 번거로웠습니다. 세션과 캐시를 위한 redis 서버를 테스트할 때 마다 매번 올리는건 개발 생산성을 낮춘다고 판단했습니다. 이러한 현상은 제 팀원에게도 나타날 것이기 때문에 지금 개선하지 않으면 팀원 수에 비례하여 개발 생산성이 낮아질 것으로 판단했습니다.
<aside> 💡 통합 테스트 과정 redis 서버를 실행(수동) → 통합 테스트 실행(수동) → 테스트 완료 → redis 서버 clear(수동)
</aside>
로컬 환경에서 서버 환경 구축을 자동화할 수 있는 툴이 있는지 조사했습니다. 여러 툴들이 있었지만, 현업에서는 도커를 사용하기 때문에 이를 선택했습니다. 또한 docker가 Ubuntu20.04에서 기본으로 설치돼있는 것으로 보아 그만큼 보편적이고 안정된 툴이라고 생각했습니다.
처음에는 각각의 Dockerfile을 Manual 하게 실행했습니다. 하지만 이는 처음 문제 상황과 달라진게 없었습니다. 이에 대안을 찾았고, docker-compose가 있다는걸 알았습니다. docker-compose 내부에서 정의된 각 컨테이너들은 하나의 네트워크로 묶이기 때문에 호스트 이름만으로도 서로의 컨테이너에 접근할 수 있었습니다. docker-compose를 이용하여 서버 환경 구축을 명령어 한번에 할 수 있었습니다.
<aside> 💡 통합 테스트 과정 docker-compose up(수동) → 통합 테스트 실행(수동) → 테스트 완료 → docker stop(수동) → docker rm(수동)
</aside>
docker-compose 구축 후에도 문제가 있었습니다. redis 서버 각각을 수동으로 구동 시키지 않고 docker-compose up으로 한번에 이를 처리하지만, 한번 실행 후에 도커를 전부 멈추고 컨테이너를 지우는 일이 번거로웠습니다. 제가 원했던건 통합 테스트를 실행하면 컨테이너가 전부 올라가고, 테스트가 끝나면 컨테이너가 내려가는 상황이었습니다.
테스트를 실행 시 도커 컨테이너를 자동으로 띄워주는 툴이 있는지 찾아봤습니다. 스프링과 호환 되면서 가장 보편적으로 쓰이는 툴은 Testcontainer 라이브러리였습니다. 해당 라이브러리의 특징은 다음과 같았습니다.
Testcontainer의 특징과 장단점을 분석한 것을 바탕하여 프로젝트에 적용했습니다. 아래 링크에 Testcontainer 적용 시 라이브러리의 작동 원리에 대한 분석 및 어떤 코드를 왜 썻는지에 대한 사고 과정이 적혀있습니다.
Testcontainer 라이브러리를 적용하여 통합 테스트 실행 시 개발자가 수동으로 무언가를 실행시키는 횟수를 4번에서 1번으로 줄였습니다. 통합 테스트를 20개 개발하면 수동으로 무언가를 실행하는게 80번이 아닌 통합 테스트 개수 20번만 실행하면 됩니다.
<aside> 💡 통합 테스트 과정 통합 테스트 실행(수동) → docker 컨테이너 up**(자동)** → 테스트 완료 → docker 컨테이너 down**(자동)**
</aside>
물론 Testcontainer를 사용하면 불편한 점이 있습니다. 아래 PR 링크 내에서도 명시 했듯이, 서버 구성 환경이 변경될 시 두 군데(yml과 자바 코드)를 수정 해야 하는 문제가 존재합니다.