| name | review-test |
| description | 이 저장소에서 작성된 테스트 코드가 프로젝트 컨벤션을 지키는지 리뷰할 때 사용한다. nested 구조, success/fail 네이밍, DisplayName, BDD 주석, 어노테이션 선택, fixture 사용을 점검한다. |
Review Test
루트 AGENTS.md와 write-test-code 규칙을 전제로 사용한다.
리뷰 목적
- 테스트 구조 일관성 점검
- 네이밍 규칙 점검
@DisplayName 규칙 점검- BDD 주석 존재 여부 점검
- 테스트 슬라이스 어노테이션 선택 점검
- fixture 사용 방식 점검
- 에러 응답 및 서비스 예외 검증 방식 점검
1. 구조
중점 확인:
- 루트 클래스명이
{원본클래스명}Test인가
- 메서드마다
@Nested inner class가 있는가
- inner class명이
{메서드명}Test 형식인가
2. 메서드 네이밍
중점 확인:
- 성공 케이스가
success()인가
- 실패 케이스가
fail_{이유}() 형식인가
3. DisplayName
중점 확인:
- 문장형인가
~테스트가 없는가- 성공/실패 prefix가 적절한가
- inner class DisplayName이
"{메서드명} - {기능}" 형식인가
4. BDD 주석
중점 확인:
세 주석이 모두 존재하는가
5. 어노테이션 선택
중점 확인:
- Controller 테스트에
@WebMvcTest 계열을 썼는가
- Service 테스트에 Mockito 기반 단위 테스트를 썼는가
- Repository 테스트에
@PersistenceTest를 썼는가
- 전체 플로우 테스트에
@IntegrationTest를 썼는가
- Controller 협력 객체를
@MockitoBean으로 주입했는가
6. Fixture 사용
중점 확인:
- 서비스 테스트에서
toMockEntity()를 쓰는가
- persistence / integration 테스트에서
toEntity()를 쓰는가
- 이미 있는 fixture 대신 직접 builder를 남발하지 않는가
7. 에러 검증
중점 확인:
- 컨트롤러/통합 테스트에서 에러 응답은
status, isSuccess, code 중심으로 검증하는가
- 에러 코드 검증 시 직접 문자열보다 ErrorCode enum의
getCustomCode()를 사용하는가
- 에러 메시지(
message)를 String literal로 직접 검증하지 않는가
- 메시지까지 API 계약인 경우에만 ErrorCode enum의
getMessage()를 사용하는가
- 서비스 단위 테스트에서
ApplicationException은 hasMessage(...)보다 getCode()로 ErrorCode enum을 검증하는가
출력 방식
- 위반 사항은 파일/라인과 함께 구체적으로 적는다.
- 가능하면 수정 방향을 예시와 함께 제안한다.
- 문제 없음이면 컨벤션상 큰 이슈 없음을 명시한다.
