# [[Testing Methodologies (테스트 방법론)|Testing Methodologies (테스트 방법론]]

## 📌 Brief Summary
테스트 방법론(Testing Methodologies)은 소프트웨어 개발 및 코드 리뷰 과정에서 프로그램의 기능적 정확성, 안정성, 보안성을 검증하기 위한 체계적인 접근 방식입니다 [1]. 자동화된 테스트(Automated Testing)를 통해 사람이 직접 리뷰하기 전 코드의 기초 결함을 걸러내고, TDD 및 BDD와 같은 방법론을 적용하여 설계 품질을 높입니다. 이는 인간 리뷰어가 사소한 스타일 오류에서 벗어나 아키텍처와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있도록 돕는 강력한 품질 게이트(Quality Gate) 역할을 수행합니다.

## 📖 Core Content
*   **테스트의 계층 구조 (Testing Pyramid):**
    *   **단위 테스트 (Unit Testing):** 개별 함수나 클래스 등 최소 단위를 독립적으로 검증함 [7, 49].
    *   **통합 테스트 (Integration Testing):** 여러 모듈 간의 상호작용과 데이터 흐름을 검증함.
    *   **E2E 테스트 (End-to-End):** 사용자 관점에서 시스템의 전체 워크플로우를 검증함.
*   **주요 개발 방법론:**
    *   **TDD (Test-Driven Development):** 실패하는 테스트를 먼저 작성하고, 이를 통과하는 최소한의 코드를 구현한 뒤 리팩토링하는 순환 방식 [49]. 코드의 테스트 용이성(Testability)을 높이고 설계를 단순화합니다.
    *   **BDD (Behaviour-Driven Development):** 사용자의 행위(Scenario)를 중심으로 테스트 케이스를 작성하여 비즈니스 요구사항과 기술적 구현 간의 간극을 좁힙니다.
*   **자동화 테스트와 코드 리뷰:**
    *   **병합 전 필수 실행:** 코드 리뷰 요청 전 개발자 스스로 테스트를 수행하여 작동하지 않는 코드가 리뷰어에게 전달되는 낭비를 막아야 합니다 [1, 2].
    *   **CI/CD 통합:** 린팅, 정적 분석, 단위 테스트를 CI/CD 파이프라인에 통합하여, 모든 검사를 통과한 코드만이 리뷰 대상이 되거나 병합되도록 강제합니다 [3, 8].
    *   **테스트 코드 리뷰:** 테스트 코드 역시 프로덕션 코드와 동일한 품질 기준으로 리뷰해야 합니다. 테스트가 엣지 케이스, 경계 조건 등을 적절히 검증하는지, 그리고 유지보수하기 쉬운 구조(예: AAA 패턴)인지 확인합니다 [8, 12].
*   **품질 지표:**
    *   **테스트 커버리지 (Test Coverage):** 작성된 코드가 테스트에 의해 얼마나 실행되는지 측정함. 일반적으로 80% 내외의 합리적인 목표를 설정합니다 [7, 15].

## ⚖️ Trade-offs & Caveats
*   **커버리지의 함정:** 100% 커버리지와 같이 비합리적이고 경직된 수치를 강제하면, 개발자가 실질적 가치가 없는 무의미한 테스트를 양산하여 생산성이 저하될 수 있습니다 [11, 17]. 숫자가 품질과 정비례하지 않음을 인지해야 합니다.
*   **불안정한 테스트 (Flaky Tests):** 외부 의존성이나 상태 공유로 인해 무작위로 실패하는 테스트는 배포 파이프라인의 신뢰도를 떨어뜨리고 개발자 경험(DX)을 해칩니다 [12, 34]. 테스트는 항상 결정론적(Deterministic)이고 독립적이어야 합니다.
*   **자동화의 한계:** 자동화 도구는 패턴 기반 결함은 잘 찾아내지만, 비즈니스 맥락이나 복잡한 아키텍처적 트레이드오프는 이해하지 못합니다. 반드시 인간의 수동 검토와 병행되어야 합니다 [19, 21].

## 🔗 Knowledge Connections

### Related Concepts
*   **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 테스트가 지속적으로 실행되고 품질 게이트 역할을 수행하는 핵심 인프라입니다.
*   **Static Code Analysis**: 코드를 실행하지 않고 잠재적 버그와 스타일 위반을 찾아내는 보완적 검증 수단입니다.
*   **Mocking & Stubbing**: 단위 테스트 시 외부 의존성을 격리하여 독립적인 테스트 환경을 구축하는 기술입니다.
*   **Shift-Left Security**: 보안 테스트를 개발 초기 단계로 앞당겨 수정 비용을 절감하는 전략입니다.

### Deeper Research Questions
*   각 프로젝트의 비즈니스 중요도와 변경 빈도에 따라 최적의 '투자 대비 효율(ROI)'을 내는 테스트 커버리지 임계값은 어떻게 산출하는가?
*   불안정한(Flaky) 테스트를 유발하는 코드 패턴(예: 시점 의존성, 글로벌 상태 공유)을 정적 분석 단계에서 사전에 필터링할 수 있는 방법은 무엇인가?
*   AI 코딩 비서가 작성한 테스트 코드의 '환각(Hallucination)' 현상을 검증하고, 누락된 엣지 케이스를 보완하기 위한 인간 리뷰어의 체크리스트는 어떻게 구성해야 하는가?
*   마이크로서비스 아키텍처(MSA)에서 서비스 간 계약 테스트(Contract Testing)를 자동화 파이프라인에 어떻게 효율적으로 통합할 수 있는가?
*   성능 테스트 및 부하 테스트와 같은 비기능적 테스트를 CI/CD 단계에서 '회귀 테스트' 형태로 운영하기 위한 전략은 무엇인가?

### Practical Application Contexts
*   **Implementation:** PR 생성 전 Pre-commit hook을 통해 린터와 단위 테스트가 자동 실행되도록 환경을 설정하여 기초 결함을 차단합니다 [46].
*   **System Design:** 테스트 간 상태 공유를 제거하고 독립적으로 실행되게 설계하여, 병렬 테스트 실행이 가능한 속도감 있는 파이프라인을 구축합니다 [47].
*   **Operation / Maintenance:** CI/CD 파이프라인에서 테스트 실패 시 병합을 강제로 차단하는 브랜치 보호 규칙을 적용하여 안정성을 확보합니다 [48].
*   **Learning Path:** 단위 테스트 프레임워크(JUnit, Jest 등) 숙지 후 TDD 및 Mocking 기법을 익히고, 최종적으로 CI/CD 연동 및 테스트 자동화 아키텍처를 설계하는 방향으로 학습합니다.
*   **My Project Relevance:** 스타일 및 기초 로직 검증을 자동화에 위임하여, 리뷰어가 시스템 아키텍처와 핵심 비즈니스 로직 논의에 집중할 수 있는 문화를 정착시킵니다.

### Adjacent Topics
*   **Technical Debt (기술 부채**: 테스트가 결여되거나 잘못 작성된 코드가 장기적으로 초래하는 유지보수 비용과 개발 속도 저하에 대해 탐구합니다.
*   **Mutation Testing**: 테스트 코드 자체의 품질(결함 발견 능력)을 측정하고 개선하는 고급 테스트 기법입니다.

---
*Last updated: 2026-05-02*
