조급하면 모래성이 될뿐

이전 포스팅에서 아래와 같은 구조로 테스트 환경을 구축하면서, 모듈 별 테스트 설정이 중복되는 것에 아쉬움이 남았다. 이 구조의 단점은 하나로 설정 가능한 정보가 API 모듈에 중복해서 관리된다는 것이었다. API 모듈: MariaDB 접속을 위한 설정, Redis 접속을 위한 설정 Domain 모듈: MariaDB 접속을 위한 설정 Redis 모듈: Redis 접속을 위한 설정 최초 위와 같은 구조로 만든 이유는 다음과 같다. 테스트 컨테이너에 의해 생성된 컨테이너의 포트는 고정적이지 않다. 따라서 DB 접속에 필요한 정보를 코드로 동적으로 세팅해주어야 한다. application.yml 파일에서 접속정보를 고정시킬 수 없다. 즉, 런타임 시점에 코드로 설정정보를 주입해야 한다. API 모듈에서, 다른..

domain 모듈에서 mariadb컨테이너가 필요한 단위테스트 할 때, properties 설정만으로 애플리케이션이 시작될 때마다 컨테이너화된 새로운 데이터베이스 인스턴스를 얻을 수 있었다. - JDBC support api 모듈에서는 추가적으로 redis 컨테이너도 필요했다. 위처럼 설정 하나로 모든 테스트에서 Redis 컨테이너를 참조하고 싶었지만... 테스트 컨테이너를 다루는 일반적인 방식으로는 불가능했다. 싱글톤으로 테스트 컨테이너를 만드는 일반적인 방식 - static final 로 선언된 컨테이너를 관리하는 추상 클래스를 정의한다. - 컨테이너가 필요한 클래스에서 이 추상 클래스를 상속하여 사용한다. - 공식문서 abstract class AbstractContainerBaseTest { st..

현재 프로젝트 구조는 위와 같다. Domain 모듈에서 Repository 계층을 책임지고 있기 때문에, 해당 단위테스트는 mariaDB Container를 사용해 해결했다. Infra 모듈에서 역시 Redis 컨테이너를 통해 단위테스트를 진행할 수 있을 것이다. 그럼 통합 테스트 환경은 어떻게 구성하는 것이 좋을까?? 처음에는 아래와 같은 구조로 통합테스트를 진행하고자 시도했다. 즉, 각 모듈의 /test/resources/application.yml에 실행에 필요한 테스트 컨테이너 환경 설정정보가 정의되어 있기 때문에 api 모듈에서는 이 정보만 참조하면 되겠다! 싶었다. 하지만 Domain 모듈의 컨테이너는 yml 설정으로 가능하지만, Infra 모듈의 컨테이너 (Redis Container)는 이..