docs(agents): 저장 시각 정밀도와 DB 왕복 검증 규칙을 명시한다

This commit is contained in:
2026-10-26 12:02:57 +09:00
parent c97b028dd5
commit 96a59021ff
3 changed files with 30 additions and 0 deletions
+13
View File
@@ -79,3 +79,16 @@
- 주석은 한 문장으로 간결하게 작성한다.
- 주석은 코드의 의도와 구조를 설명한다.
- 주석은 코드 변경 시 업데이트를 잊지 않는다.
### 12) DB 저장 시각과 응답 정밀도
- 상태 변경 시각을 DB에 저장하면서 API 응답에도 반환할 때는 먼저 해당 컬럼의 DDL 정밀도를 확인한다.
MySQL의 소수초 정밀도를 지정하지 않은 `TIMESTAMP`/`DATETIME`은 초 단위다. `(3)`/`(6)` 컬럼에 초 절삭을 일괄 적용하지 않는다.
- OS/JDK의 `LocalDateTime.now()`는 나노초까지 반환할 수 있고, H2/JDBC/MySQL은 저장 시 반올림·절삭할 수 있다.
로컬에서 DB 재조회값과 응답이 같았다는 사실만으로 다른 OS/JDK에서도 같다고 가정하지 않는다.
- 시각을 한 번 얻고 저장 컬럼의 정밀도·업무 계약에 맞게 정규화한 단일 변수를 엔티티와 응답에 공통 사용한다.
선물의 소수초 없는 TIMESTAMP 상태 시각은 기존 관례대로 `now.truncatedTo(ChronoUnit.SECONDS)`를 사용한다.
- 정밀도 조정은 해당 업무 저장 경계에서 처리한다. 응답만 절삭하거나 저장/응답에서 각각 `now()`를 호출하지 않는다.
시간대 변환은 별도 계약이며 이 문제를 고치기 위해 전역 `toUtcIso`, Jackson, timezone 또는 DDL을 임의 변경하지 않는다.
- 관련된 메서드만 수정하고 다른 도메인/상태 시각을 무단으로 일괄 정규화하지 않는다. 검증은 테스트 스타일의 왕복 규칙을 따른다.
- 선례: `82ce6f88`의 `GiftAdminService.cancelGift` 및 선물하기 계획 `P14-T4`.
같은 원인으로 수령확인 `deliveredAt` 비교가 재발해 `P16-R1`에서 이 규칙을 명시했다.
+14
View File
@@ -18,3 +18,17 @@
- embedded Redis는 모든 테스트에 전역 등록하지 않는다. `src/test/resources/META-INF/spring.factories`로 `EmbeddedRedisInitializer`를 등록하면 Redis가 필요 없는 `@DataJpaTest`까지 Redis를 시작하므로 금지한다.
- Redis가 필요한 통합 테스트만 `@ContextConfiguration(initializers = [EmbeddedRedisInitializer::class])`로 명시적으로 opt-in 한다.
- Redis가 필요 없는 JPA/QueryDSL 슬라이스 테스트는 기존 관례처럼 `@DataJpaTest(properties = ["spring.cache.type=none"])`로 캐시를 끈다.
## 저장 시각·응답 왕복 검증 규칙
- DB 재조회 시각과 API 응답을 비교하는 테스트는 OS의 현재 시각만 사용하지 않는다. 기존 시각 주입 seam을 재사용해
나노초 `0`, `123456789`, `999999999`와 `23:59:59` 같은 초/날짜 경계 입력을 고정한다.
- 실제 repository/DB에 저장한 뒤 `flush`/`clear`/재조회 또는 별도 트랜잭션 재조회로 DB 정밀도 변환을 통과시킨다.
저장 인자나 managed entity, mock 반환값만 비교해서는 DB 왕복을 검증했다고 하지 않는다.
- 초 단위 컬럼이면 고정 기대값의 나노초가 0이고 다음 초/날짜로 반올림되지 않으며, DB 값과 서비스 결과 및 HTTP 응답이
기존 직렬화 계약으로 정확히 일치하는지 확인한다. 기존 실제 HTTP의 완전 일치 assertion도 유지한다.
- assertion 양쪽을 잘라 비교하거나 시간 허용오차·문자열 일부 비교·skip으로 저장/응답 불일치를 숨기지 않는다.
먼저 미정규화 코드의 실패를 확인하고 production 저장 경계에서 같은 값을 쓰도록 고친다.
- H2 기본 timestamp 정밀도가 운영 MySQL DDL과 같다고 가정하지 않는다. 사용한 DB/컬럼과 검증 경계를 기록하고,
CI의 expected/actual이 없으면 고정 입력 재현 결과와 CI 원본 재현 여부를 구분한다.
- 선례: `GiftAdminServiceTest.shouldPersistAndReturnSameSecondPrecisionCancellationTime` 및
선물하기 계획 `P14-T4`/`P16-R1`. 공유 formatter의 변경 없이 업무별 단일 시각 정규화를 검증한다.