조급하면 모래성이 될뿐

Why? 프로젝트를 하면서 지역별로 현재 참여 가능한 게시글이 몇 개인지 응답하는 API를 구현해야 했다. 이 API의 응답은 지역별로 참여가능한 글의 개수를 확인하고, 검색 필터조건으로 사용하기 위함이었다. 다음과 같은 데이터가 있다면 id city province status 1 경기도 성남시 분당구 IN_PROGRESS 2 경기도 성남시 분당구 DONE 3 경기도 용인시 IN_PROGRESS 4 서울특별시 서초구 DONE 아래와 같은 정보를 만들어야 한다. 경기도: 2 성남시 분당구 1 용인시: 1 서울특별시: 0 서초구: 0 이 API의 응답은 자주 바뀌지 않고 고정적이다. 바뀌는 경우는 게시글 등록, 삭제, 상태가 변경되었을 때이다. 위 문제를 해결하기 위해서는 Board 테이블을 전체 조회하..

이전 포스팅에서 아래와 같은 구조로 테스트 환경을 구축하면서, 모듈 별 테스트 설정이 중복되는 것에 아쉬움이 남았다. 이 구조의 단점은 하나로 설정 가능한 정보가 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)는 이..

현재 프로젝트에서는 RDS를 mariadb로 구성하여 사용하고 있다. 이를 위해 mariadb 테스트 컨테이너 환경을 구축했다. 또한 테스트 라이브러리로는 kotest를 사용하고 있다. 1. 테스트 컨테이너 의존성 추가. build.gradle.kts testImplementation("org.testcontainers:testcontainers:$testContainerVersion") testImplementation("org.testcontainers:junit-jupiter:$testContainerVersion") testImplementation("org.testcontainers:mariadb:$testContainerVersion") 2. mariadb 테스트 컨테이너 설정 TestCont..