---
id: wiki-2026-0507-023
title: 테스트 전략 및 방법론
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [wiki-2026-0507-023, Testing Methodologies, 테스트 방법론, TDD, BDD, Unit Testing, Test Strategy]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: [Testing, Software Engineering, Quality Assurance, TDD, Automation, CI/CD]
raw_sources: [직접 입력]
last_reinforced: 2026-05-07
github_commit: pending
tech_stack:
  language: unspecified
  framework: unspecified
---

# 테스트_전략_및_방법론

## 📌 한 줄 통찰 (The Karpathy Summary)
> "테스트는 단순히 버그를 찾는 행위가 아니라, 코드의 변경에 대한 용기(Confidence)를 부여하고 설계의 품질을 강제하는 엔지니어링 규율이다."

---

## 📖 구조화된 지식 (Synthesized Content)
**추출된 패턴:**
> 자동화된 테스트를 통해 사소한 로직 결함을 기계가 선별하게 함으로써, 인간 리뷰어가 아키텍처와 비즈니스 맥락 등 고차원적 가치에 집중할 수 있는 '품질 게이트(Quality Gate)'를 구축하는 것이 핵심이다.

**세부 내용:**
- **테스트 계층 구조 (Testing Pyramid):**
  - **단위 테스트 (Unit Test):** 개별 함수/클래스 독립 검증. 가장 빠르고 많아야 함.
  - **통합 테스트 (Integration Test):** 모듈 간 상호작용 및 데이터 흐름 검증.
  - **E2E 테스트 (End-to-End):** 사용자 시나리오 기반 전체 시스템 흐름 검증.
- **주요 방법론:**
  - **TDD (Test-Driven Development):** [실패 테스트 작성 -> 구현 -> 리팩토링] 순환을 통해 테스트 용이성이 높은 설계 유도.
  - **BDD (Behaviour-Driven Development):** 사용자 행위(Scenario) 중심 서술로 요구사항과 구현의 간극 해소.
- **자동화 및 CI/CD 통합:**
  - **Pre-commit Hooks:** 코드 제출 전 기초 테스트 및 린팅 강제.
  - **Branch Protection:** 모든 테스트와 품질 검사를 통과해야만 병합 가능한 규칙 적용.
- **품질 지표와 한계:**
  - **커버리지 (Coverage):** 80% 내외의 합리적 목표 설정 권장. 100% 강제는 무의미한 테스트 양산을 초래할 수 있음.
  - **결정론적 테스트 (Deterministic):** 무작위로 실패하는 'Flaky Test'를 제거하여 파이프라인 신뢰도 확보.

---

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- 프로젝트 초기 단계에서 품질 관리 및 배포 자동화 파이프라인을 설계해야 할 때.
- 코드의 유지보수성이 떨어지고 변경 시마다 버그가 자주 발생하여 시스템적인 보완이 필요할 때.
- 신입 개발자나 협업 팀에게 우리 팀의 테스트 표준을 안내해야 할 때.

**언제 이 지식을 쓰면 안 되는가:**
- 일회성 스크립트나 실험적 프로토타이핑과 같이 코드 수명이 극히 짧은 경우.

**이 지식을 적용할 때의 권장 절차:**
1. **단위 테스트 구축:** 핵심 비즈니스 로직에 대해 작은 단위의 테스트부터 작성.
2. **Mocking 활용:** 데이터베이스나 외부 API 등 의존성을 격리하여 테스트 속도와 독립성 확보.
3. **CI 연동:** GitHub Actions 등을 통해 모든 PR에 대해 자동으로 테스트가 실행되도록 설정.
4. **리뷰 문화:** 테스트 코드 자체도 리뷰 대상에 포함하여 테스트의 적절성과 엣지 케이스 검증 여부 확인.

**주의사항 또는 알려진 한계:**
- 자동화 테스트는 패턴 기반 오류는 잘 찾지만, 비즈니스 맥락의 논리적 모순은 인간의 검토가 여전히 필요함.
- 테스트 코드가 프로덕션 코드보다 비대해지면 오히려 유지보수의 짐이 될 수 있으므로, '가치 있는 테스트'에 집중해야 함.

---

## 🧪 검증 상태 (Validation)
- **정보 상태:** verified
- **출처 신뢰도:** A
- **검토 이유:** 해당 없음

---

## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** [[Testing Methodologies (테스트 방법론)]], [[Testing Strategy]], [[Testing]], [[Unit Testing]], [[Integration-Testing-for-AI]] 등 다수
- **처리 방식:** MERGE
- **처리 이유:** 테스트의 이론, 계층, 자동화 전략을 담은 20여 개의 중복 문서를 통합하여 전사적 테스트 표준 가이드로 정립함.

---

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 단순 '버그 탐지'를 넘어 '리뷰어 에너지 보존'과 '설계 품질 강제'를 테스트의 핵심 가치로 격상함.

---

## 🔗 지식 연결 (Graph)
- **Parent:** [[10_Wiki/Topics]]
- **Related:** , [[CI_CD_파이프라인_자동화]]
- **Raw Source:** 직접 입력

---

## 🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-07 | 20개 이상의 테스트 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*