122 lines
5.5 KiB
Markdown
122 lines
5.5 KiB
Markdown
---
|
|
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:** [[Git_버전_관리_전략]], [[SAST_정적_보안_진단_체계]], [[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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)* |