일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- 백준
- multimodule testcontainers
- redissonlock aop
- 우아한 테크러닝
- spring aop
- OptimisticLock
- @transactional
- RefreshToken
- netty
- springsecurity
- java
- TestContainers
- 소수찾기 java
- 낙관적 락 재시도
- ObjectOptimisticLockingFailureException 처리
- interface
- 멀티모듈 테스트컨테이너
- S3
- DI
- Spring Cloud Gateway
- Invalid property 'principal.username' of bean class
- AccessToken
- 알고리즘
- jpa
- aop
- kotest testcontainers
- spring DI
- 낙관적 락 롤백
- Today
- Total
목록구현 기록 (11)
조급하면 모래성이 될뿐
현재 프로젝트에서는 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를..
개인 프로젝트를 진행하면서, 계정의 권한별로 보여지는 메뉴리스트 구성을 달리하였다. 프로젝트의 내용은 자영업자들이 이벤트를 등록하면, 일반유저들이 이용하는방식이다. ㅇ 권한리스트 일반사용자 : ROLE_NORMAL 사업자 : ROLE_PARTNER, ROLE_NORMAL 일반사용자는 [ 가게등록 ] 메뉴를 볼 수 있다. [ 가게등록 ]메뉴는 사업자를 등록하는 메뉴이고, 사업자등록시 ROLE_PARTNER권한을 부여받는다. 사업자를 등록한 계정은 더이상 [ 가게등록 ]메뉴를 볼 필요가없다. 그러나, 일반사용자가 로그인 후, 사업자등록을하게되면 ROLE_NORMAL에 ROLE_PARTNER의 권한이 추가되지만, Reload된 메뉴구성에는 여전히 [ 가게등록 ]메뉴가 보이고있다.. 원인은 최초 로그인시 Spr..