| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- DI
- TestContainers
- kotest testcontainers
- 멀티모듈 테스트컨테이너
- ObjectOptimisticLockingFailureException
- spring aop
- multimodule testcontainers
- jpa
- 알고리즘
- spring DI
- @transactional
- S3
- interface
- OptimisticLock
- aop
- 백준
- 소수찾기 java
- 우아한 테크러닝
- Invalid property 'principal.username' of bean class
- redissonlock aop
- springsecurity
- 형상관리
- netty
- ObjectOptimisticLockingFailureException 처리
- AccessToken
- 낙관적 락 롤백
- 낙관적 락 재시도
- java
- Spring Cloud Gateway
- RefreshToken
- Today
- Total
목록구현 기록/TestContiners (5)
조급하면 모래성이 될뿐
MariaDB TestContiner 적용
현재 프로젝트에서는 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..
Why? 테스트 코드를 작성하고, 프로젝트를 완성해 나가면서 항상 테스트 환경에 대한 고민을 하게 되었다. 대표적으로 Repository는 어디를 붙어야 할지.. 또 특정 서버와 연결을 해두었다면 (test 서버), 해당 DB의 데이터를 비워주거나 누적되지 않게 따로 관리를 해야 할지... -> 멱등성이 깨지는 것에 대해 계속 신경이 쓰였다. in-memory DB를 사용해도 좋지만, 이 경우 운영환경에서 예상하지 못한 예외가 발생할 수 있다. 지난 프로젝트에서는 H2 DB로 테스트를 하다가 운영배포를 할 때 예약어로 인한 문제가 발생했다. (user, row, column) - MySQL 예약어 목록 때문에 운영환경과 최대한 유사하게 테스트 환경을 구축하고자 했다. 처음에는 Docker-Compose를..