일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 우아한 테크러닝
- 멀티모듈 테스트컨테이너
- ObjectOptimisticLockingFailureException 처리
- springsecurity
- TestContainers
- 낙관적 락 재시도
- AccessToken
- 백준
- Invalid property 'principal.username' of bean class
- interface
- DI
- spring aop
- kotest testcontainers
- Spring Cloud Gateway
- spring DI
- aop
- jpa
- multimodule testcontainers
- netty
- OptimisticLock
- S3
- ObjectOptimisticLockingFailureException
- RefreshToken
- redissonlock aop
- 형상관리
- 낙관적 락 롤백
- java
- 알고리즘
- 소수찾기 java
- @transactional
- Today
- Total
목록멀티모듈 테스트컨테이너 (2)
조급하면 모래성이 될뿐
이전 포스팅에서 아래와 같은 구조로 테스트 환경을 구축하면서, 모듈 별 테스트 설정이 중복되는 것에 아쉬움이 남았다. 이 구조의 단점은 하나로 설정 가능한 정보가 API 모듈에 중복해서 관리된다는 것이었다. API 모듈: MariaDB 접속을 위한 설정, Redis 접속을 위한 설정 Domain 모듈: MariaDB 접속을 위한 설정 Redis 모듈: Redis 접속을 위한 설정 최초 위와 같은 구조로 만든 이유는 다음과 같다. 테스트 컨테이너에 의해 생성된 컨테이너의 포트는 고정적이지 않다. 따라서 DB 접속에 필요한 정보를 코드로 동적으로 세팅해주어야 한다. application.yml 파일에서 접속정보를 고정시킬 수 없다. 즉, 런타임 시점에 코드로 설정정보를 주입해야 한다. API 모듈에서, 다른..
현재 프로젝트 구조는 위와 같다. Domain 모듈에서 Repository 계층을 책임지고 있기 때문에, 해당 단위테스트는 mariaDB Container를 사용해 해결했다. Infra 모듈에서 역시 Redis 컨테이너를 통해 단위테스트를 진행할 수 있을 것이다. 그럼 통합 테스트 환경은 어떻게 구성하는 것이 좋을까?? 처음에는 아래와 같은 구조로 통합테스트를 진행하고자 시도했다. 즉, 각 모듈의 /test/resources/application.yml에 실행에 필요한 테스트 컨테이너 환경 설정정보가 정의되어 있기 때문에 api 모듈에서는 이 정보만 참조하면 되겠다! 싶었다. 하지만 Domain 모듈의 컨테이너는 yml 설정으로 가능하지만, Infra 모듈의 컨테이너 (Redis Container)는 이..