Files
api2/docs/testing-strategy.md
T
2026-07-20 17:49:24 +09:00

90 lines
3.7 KiB
Markdown

# 테스트 전략
## 목적
- 기능 이관과 신규 개발에서 테스트 범위를 과도하게 넓히지 않고 위험도에 맞춰 검증한다.
- 단위 테스트, 통합 테스트, 실제 연동 검증의 책임을 분리한다.
- 기능 또는 모듈을 완료할 때 실제 동작과 데이터 반영까지 확인한다.
## 테스트 구분
| 구분 | 목적 | 외부 의존성 | 실행 시점 |
|---|---|---|---|
| 단위 테스트 | 분기, 결과 코드, DTO/VO 변환, 권한 판단 검증 | 사용하지 않음 | 구현 중 수시 실행 |
| 통합 테스트 | Spring, MyBatis, Security, DB와 모듈 간 연결 검증 | 테스트 DB 등 필요한 의존성만 사용 | 모듈 기능 완료 시 |
| 실제 연동 검증 | 실행 API와 실제 데이터 저장·갱신 결과 확인 | 기능이 사용하는 실제 의존성만 사용 | 모듈 이관 완료 후 |
## Red-Green 흐름
1. 기능의 핵심 성공·실패 조건을 테스트로 먼저 작성한다.
2. 테스트가 실패하는 Red 상태를 확인한다.
3. 최소 구현으로 테스트를 통과하는 Green 상태를 만든다.
4. 필요할 때만 리팩터링하고 같은 테스트를 다시 실행한다.
이미 이관이 끝난 기능에는 기존 동작을 고정하는 회귀 테스트를 추가한다. 구현된 기능을 의도적으로 깨뜨려 Red 상태를 재현하지 않는다.
## 단위 테스트 기준
- 단순 CRUD 보일러플레이트마다 테스트를 강제하지 않는다.
- 다음 중 하나가 있으면 단위 테스트를 우선 추가한다.
- 권한 또는 역할 분기
- 중복·상태·입력값 검증
- 여러 DTO/VO 간 변환
- 날짜, 금액, 카운트 등 계산
- 실패 결과 코드와 예외 처리
- 외부 DB, Redis, 파일 시스템, HTTP 호출은 Mock 또는 Fake로 대체한다.
## 통합 테스트 기준
- 모듈 단위 작업이 완료되면 해당 실행 모듈과 Core를 함께 검증한다.
- MyBatis Mapper XML, namespace, SQL 결과 매핑, Spring Bean 구성, Security 경로를 확인한다.
- 테스트 환경은 개발 공용 데이터가 아닌 전용 테스트 DB와 테스트 Redis를 우선 사용한다.
- Redis Pub/Sub처럼 커밋 후 동작이 필요한 기능은 실제 트랜잭션 커밋과 수신 결과를 검증한다.
## 실제 연동 검증 기준
실제 연동 검증은 모든 기능에 같은 항목을 강제하지 않는다.
```text
기본: API 호출 -> DB 저장 또는 변경 확인 -> 조회 API 확인
Redis 사용 기능: Redis Key, 캐시, Pub/Sub 수신 결과 추가 확인
파일 사용 기능: 파일 저장, 조회, 삭제, 경로 처리 추가 확인
외부 API 기능: 요청, 응답, 실패 처리 추가 확인
메시지 기능: 발행, 수신, 재처리 결과 추가 확인
```
- 실제 개발 데이터를 변경해야 하면 테스트용 식별값을 사용한다.
- 등록·수정·삭제 테스트 후에는 테스트 데이터를 삭제하거나 원복한다.
- 검증하지 못한 외부 의존성은 이유와 미검증 범위를 남긴다.
## 실행 순서
```text
기능 구현 중
-> 관련 모듈 compileJava
-> 필요한 단위 테스트
모듈 작업 완료
-> Core 및 실행 모듈 build
-> 통합 테스트
-> 실제 API / DB / 기능별 의존성 검증
배포 전
-> Admin / Front 전체 빌드
-> 핵심 시나리오 회귀 테스트
```
## Gradle 기준
- 현재 최소 컴파일 검증 명령
```bash
./gradlew :01-api-core:compileJava
./gradlew :02-api-admin:compileJava
./gradlew :03-api-front:compileJava
```
- 단위 테스트와 통합 테스트가 추가되면 `unitTest`, `integrationTest` 태스크로 분리한다.
- 일상 개발에서는 빠른 단위 테스트를 우선 실행하고, 모듈 완료·배포 전에는 통합 테스트까지 실행한다.