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