# 테스트 커버리지 및 모킹 가이드

이 문서는 백엔드 테스트 코드 작성 시 필수적인 개념인 **테스트 커버리지**와 **모킹(Mocking)**에 대해 설명합니다.

---

## 1. 테스트 커버리지 (Test Coverage)

**정의:** 테스트 코드가 전체 소스 코드 중 얼마나 많은 부분을 실행(검증)했는지를 나타내는 백분율(%) 지표입니다.

### 왜 중요한가요?
*   **안정성 지표:** 커버리지가 높을수록 코드의 많은 부분이 자동화된 검증을 거쳤음을 의미합니다.
*   **사각지대 발견:** 테스트되지 않은 '죽은 코드(Dead Code)'나 누락된 예외 처리 분기(if-else)를 찾아낼 수 있습니다.
*   **리팩토링 자신감:** 커버리지가 높으면 기존 기능을 깨뜨리지 않고 코드를 수정하기가 훨씬 수월합니다.

### 어떻게 확인하나요? (Go 기준)
```bash
# 1. 테스트 실행 및 기록 저장
go test -coverprofile=coverage.out ./...

# 2. 브라우저에서 시각적으로 확인 (어느 줄이 안 됐는지 색상으로 표시됨)
go tool cover -html=coverage.out
```

---

## 2. 모킹 (Mocking)

**정의:** 테스트하려는 대상이 의존하는 외부 요소(데이터베이스, 외부 API, 다른 서비스 등)를 **동작만 흉내 내는 가짜 객체(Mock)**로 대체하는 기술입니다.

### 왜 필요한가요?
*   **독립적 환경:** 실제 Ory Hydra 서버가 꺼져 있어도 백엔드 로직만 따로 테스트할 수 있습니다.
*   **결정적 테스트:** 네트워크 상태에 상관없이 항상 동일한 결과를 얻을 수 있습니다.
*   **예외 상황 시뮬레이션:** "서버 점검 중(503 에러)"과 같은 특수한 상황을 강제로 만들어 내 코드가 잘 대응하는지 확인할 수 있습니다.

### `MockRelyingPartyRepository`는 무엇인가요?
사용자께서 보신 `MockRelyingPartyRepository`는 라이브러리가 제공하는 함수가 아니라, **테스트를 위해 직접 만든 구조체**입니다.

1.  **구조체 정의:** `RelyingPartyRepository`라는 인터페이스를 똑같이 흉내 내도록 우리가 직접 코드를 짭니다.
2.  **라이브러리 활용:** 이때 `github.com/stretchr/testify/mock` 라이브러리를 사용하여 "이 함수가 호출되면 어떤 값을 반환하라"는 지시를 쉽게 내릴 수 있게 만듭니다.

**예시 코드:**
```go
// 1. 우리가 직접 만든 가짜 객체 (이름은 마음대로 정할 수 있음)
type MockRelyingPartyRepository struct {
    mock.Mock // testify 라이브러리의 기능을 빌려옴
}

// 2. 실제 DB 저장소인 척 함수를 구현
func (m *MockRelyingPartyRepository) Create(ctx context.Context, rp *domain.RelyingParty) error {
    args := m.Called(ctx, rp) // 호출 기록
    return args.Error(0)      // 설정된 에러 반환
}
```

---

## 3. 요약 및 원칙

1.  **모킹을 통해 커버리지를 높이세요:** 실제 환경에서 만들기 힘든 에러 상황을 모킹으로 구현하여 코드의 예외 처리 로직(Red line)을 검증하세요.
2.  **핵심 비즈니스 로직 우선:** 단순한 설정값 조회보다는 **로그인, 권한 체크, 데이터 통합** 등 서비스의 핵심 기능 커버리지를 **80% 이상**으로 유지하는 것을 권장합니다.
3.  **수치에 집착하지 마세요:** 커버리지 100%가 "버그 없음"을 보장하지는 않습니다. 의미 있는 테스트 케이스를 작성하는 것이 더 중요합니다.
