Testcontainer 도입기

들어가며

개인 프로젝트에서 유닛 테스트를 짜고 있었다. SMS, 이메일 인증 로직을 테스트 하려고 하다가 고민에 빠졌다. 해당 로직은 외부 캐시 서비스를 사용 해서 인증번호 대조를 진행한다. 이를 테스트 하기 위한 방법론에 대한 고민에 빠진 것이다. 고민은 Spy 객체를 만들어서 코드로 로직을 검증할까, 아니면 실제 데이터를 가지고 검증을 할까 고민이었다. 해당 서비스는 외부 서비스를 의존하는 서비스라서 자바 코드로 검증하기엔 단지 flow만 검증하는 느낌이었다. 그래서 flow 뿐만 아니라 데이터도 검증 해서 더 정확히 검증 할 수 있게 실제로 Redis를 붙여서 검증하기로 결정 하였다. Mockist인 나로서는 고민이 되는 부분이었다.

 

해결

애플리케이션을 전부 올리는 SpringBootTest를 사용하기엔 테스트 시간을 너무 소비하는 느낌이어서 생산성이 떨어질 것 같았다. 그래서 test profile 전용 application yaml 파일을 만들고 테스트에 쓰일 Redis config 파일을 만들었다. 그 다음으로 Redis를 실행 시켜야 하는데 배포 전에 CI 가 실행 되는 github actions VM 에 매번 이러한 테스트가 생길 때마다 해당 하는 이미지를 올리는 등 이러한 관리 공수가 들것이라고 생각했다. 매번 CI script 코드도 수정 해야 하는데, 테스트 코드와 script 싱크를 맞추는 것도 추후 서비스가 더 커지면 귀찮은 일이라고 느껴질 수 있겠다고 생각했다. 그래서 이것도 자동화 하고싶었다. 그래서 github actions VM에 도커 환경을 세팅 해준 후 ./gradlew build 을 해주면 자동으로 @Testcontainer가 붙은 클래스에서 필요한 이미지를 세팅 해주는 테스트 환경을 구성했다.

 

기대할 수 있는 점

Testcontainer를 활용하면 앞으로 다양하게 테스트를 운영 환경이랑 최대한 비슷하게 해볼 수 있을거라고 기대한다. 지금까지 integration test는 H2 in-memory 디비로 했었지만 한계가 있었다. 호환하지 않은 문법 등 많아서 테스트를 위해 관리 해야 할 점들이 많았었다. 그런점에서 운영 환경이랑 비슷하다고 생각이 안되었다. (그렇다고 해서 도커를 띄워서 운영 환경을 만들 수 없다는건 아니긴 하다. 만들 수는 있지만 억지로 만들어주는 느낌으로 운영 코드랑 필요한 이미지를 싱크를 CI script로 맞춰 줘야 하는 단점이 있다.) 그러나 Testcontainer는 필요한 이미지를 코드단에서 관리가 가능하기 때문에 테스트에 더 집중할 수 있다고 생각한다. 그리고 코드로 운영 환경을 최대한 구성할 수 있어서 테스트를 실제 운영환경이랑 비슷하게 할 수 있다는 장점이 있었다.