Testing Strategy

Testing Strategy

테스트 구조

단위 테스트 (Unit)        — Fake 구현체
  |
  v
컨트롤러 테스트 (Slice)   — @WebMvcTest + MockMvc
  |
  v
통합 테스트 (Integration) — TestContainers
  |
  v
부하 테스트 (Load)
인수 테스트 (Acceptance)
스파이크 테스트 (Spike)

---

단위 테스트

• JUnit5
• application 모듈 (서비스/유스케이스 레이어): Fake 구현체로 외부 의존성 대체
  • FakeApplyRepository, FakeStudyPostRepository, FakeUserRepository 등 인메모리 구현체
  • FakeKafkaMessagePublisher, FakeRedisMessagePublisher 등
  • Mock(Mockito)과 달리 실제 동작 로직이 있어 결과 기반으로 검증

---

컨트롤러 테스트

• @WebMvcTest + MockMvc
• presentation 모듈: Controller 슬라이스만 로딩
• UseCase는 Mockito Mock 처리
• 인증(SecurityMockMvcRequestPostProcessors.authentication) 포함 요청 검증
• HTTP 상태 코드, 응답 JSON 구조 검증

---

통합 테스트

• TestContainers 기반 실제 인프라 사용
  • MySQL 8.0.36 컨테이너
  • Redis 7.4 컨테이너
• AbstractIntegrationTest 상속으로 컨테이너 공유 (클래스별 재시작 없음)
• @SpringBootTest + 실제 Bean 주입
• infrastructure 모듈 Repository 레이어 쿼리 정확성, 트랜잭션 검증

의존성 처리 원칙

의존성	처리 방식
MySQL	TestContainers 실제 컨테이너
Redis	TestContainers 실제 컨테이너
Kafka	FakeKafkaMessagePublisher
Elasticsearch	@MockitoBean

---

부하 테스트

• 도구: k6 (스크립트 레포 외부 실행)
• 테스트 규모: 10,000 VUs, 100,000건 요청

측정 지표

• RPS, p(95) 응답시간, 에러율, 커넥션 풀 포화 여부

---

인수 테스트

• 도구: RestAssured + @SpringBootTest(RANDOM_PORT)
• 목적: 기능 명세 기준으로 전체 API 흐름을 사람이 읽을 수 있는 형태로 검증

계획 시나리오

시나리오: 스터디 지원 승인 흐름
  Given 게시글 작성자 A, 지원자 B가 존재한다
  When  B가 A의 게시글에 지원한다
  Then  A에게 지원 알림이 발송된다
  When  A가 B의 지원을 승인한다
  Then  B에게 승인 알림이 발송된다
  And   팀 채팅방이 자동 생성된다

---

스파이크 테스트

• 도구: k6
• 목적: 트래픽 급증 시 Circuit Breaker, Rate Limit 동작 검증, 복구 시간 측정

계획 시나리오

stages: [
  { duration: '10s', target: 10 },
  { duration: '30s', target: 3000 },
  { duration: '10s', target: 10 },
]

검증 항목

• Rate Limit 429 응답 정상 반환 여부
• Circuit Breaker OPEN 전환 시점
• 스파이크 해소 후 정상 응답 복구 시간
• DLT에 쌓인 실패 메시지 수