sodalive-backend-spring-boot/docs/agent-guides/테스트스타일.md

# 테스트 스타일

## 테스트 스타일 규칙
- 테스트 프레임워크: JUnit 5 (`useJUnitPlatform()`)
- 신규 기능, 버그 수정, 리팩터링, 동작 변경은 TDD를 기본 프로세스로 따른다.
- TDD 순서는 RED(실패 테스트 작성) → 실패 확인 → GREEN(최소 구현) → 통과 확인 → REFACTOR(정리) → 회귀 확인 순서로 진행한다.
- 실패 테스트는 실제 구현 결함 또는 미구현 동작 때문에 실패해야 하며, 오타/설정 오류/테스트 데이터 오류 때문에 실패한 상태로 RED를 통과한 것으로 보지 않는다.
- 테스트 작성이 현실적으로 불가능한 작업은 계획 문서에 이유와 대체 검증 방법을 명시한다.
- 도메인 모델과 엔티티는 유닛 테스트로 작성한다.
- 서비스와 컨트롤러는 통합 테스트(`@SpringBootTest`)로 작성한다.
- 목킹은 정말 필요한 경우가 아니면 사용하지 않는다.
- 검증: `assertEquals`, `assertThrows` 패턴 준수.
- 테스트 이름은 의도가 드러나는 영어 문장형(`should...`)을 유지한다.
- 테스트는 DisplayName으로 한국어 설명을 추가한다.
- 예외 상황이 있는지 확인하고 예외 상황에 대한 테스트 케이스를 추가한다.

## Redis 테스트 격리 규칙
- 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의 변경 없이 업무별 단일 시각 정규화를 검증한다.