[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,162 +1,173 @@
|
||||
---
|
||||
id: wiki-2026-0508-test-driven-development
|
||||
title: Test Driven Development
|
||||
title: Test-Driven Development
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [TDD, Red-Green-Refactor, test first]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [tdd, testing, software-engineering, ai-aided]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: pytest
|
||||
---
|
||||
|
||||
# Test-Driven Development
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Test-Driven Development(TDD)는 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 애플리케이션의 로직을 검증하는 소프트웨어 개발 패턴입니다[1]. 프레임워크별 실전 설계 패턴에서 TDD는 비즈니스 로직을 외부 인프라나 UI로부터 독립시켜 철저히 테스트함으로써, 시스템의 신뢰성과 유지보수성을 극대화하는 핵심적인 역할을 수행합니다[1, 2]. 주로 클린 아키텍처나 육각형 아키텍처와 결합하여 모듈화되고 확장 가능한 시스템을 구축하는 데 활용됩니다[3, 4].
|
||||
## 매 한 줄
|
||||
> **"매 Red → Green → Refactor 매 fail-first feedback loop"**. Kent Beck (Extreme Programming, ~2003) origin. 2026 매 AI-pair (Claude Code, Cursor) 의 default mode — agent의 test 먼저 generate 후 implementation 의 iterate.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **TDD의 핵심 원칙 및 목적**
|
||||
TDD는 실제 구현 코드를 작성하기 전에 테스트를 먼저 작성하는 것을 원칙으로 합니다. 이 접근 방식은 애플리케이션의 핵심 비즈니스 로직이 철저히 테스트되도록 보장하여, 코드의 신뢰성(reliability)과 향후 변경에 대한 유지보수성(maintainability)을 향상시킵니다[1].
|
||||
## 매 핵심
|
||||
|
||||
* **모바일 프레임워크 환경에서의 TDD (Flutter)**
|
||||
Flutter 생태계에서 가장 중요한 실전 설계 패턴은 비즈니스 로직과 UI 위젯을 엄격하게 분리하는 것입니다. 이를 위해 개발 커뮤니티는 클린 아키텍처(Clean Architecture)와 TDD 패턴을 적극적으로 수용하고 있습니다[2]. 실무에서는 앱을 프레젠테이션, 도메인, 데이터 등 여러 계층으로 분리하고 BLoC(Business Logic Component) 상태 관리 패턴과 TDD를 결합하여 확장 가능한 최신 모바일 애플리케이션을 구축합니다[1, 3].
|
||||
### 매 Cycle
|
||||
1. **Red**: 매 failing test 의 write (no impl yet).
|
||||
2. **Green**: 매 minimum code 의 test 의 pass.
|
||||
3. **Refactor**: 매 clean up, 매 test still green.
|
||||
|
||||
* **백엔드 프레임워크 환경에서의 TDD (Spring Boot 및 육각형 아키텍처)**
|
||||
Spring Boot와 같이 엔터프라이즈 환경에서 주로 사용되는 육각형 아키텍처(Hexagonal Architecture)에서도 TDD는 필수적인 실전 패턴으로 자리 잡고 있습니다. 백엔드 시스템에서는 비즈니스 로직을 검증할 때 실제 데이터베이스(DB) 환경에 의존하지 않고, H2와 같은 인메모리(In-Memory) DB를 사용하거나 Mockito와 같은 모킹(Mocking) 도구를 활용하여 도메인 로직만을 완전히 독립적으로 검증하는 방식으로 TDD를 적용합니다[4].
|
||||
### 매 Levels
|
||||
- **Unit**: pure function, 1 class.
|
||||
- **Integration**: 매 DB / network boundary.
|
||||
- **Acceptance / E2E**: 매 user flow.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
제공된 소스에 TDD 자체의 본질적인 단점이나 제약 사항에 대한 직접적인 정보는 부족합니다.
|
||||
### 매 vs BDD
|
||||
- TDD: developer-facing, 매 method-level.
|
||||
- BDD: stakeholder-facing, 매 Given-When-Then, Cucumber/Behave.
|
||||
|
||||
다만, TDD를 위해 필수적으로 동반되는 **모킹(Mocking) 기술 사용에 관한 치명적인 부작용(Trade-off)**이 명시되어 있습니다.
|
||||
비즈니스 로직을 독립적으로 테스트하기 위해 Mockito 등의 모킹 프레임워크를 과도하게 사용할 경우, 도메인의 기능적으로 잘못된 동작을 테스트 코드 내에 하드코딩하게 될 위험이 있습니다[5, 6]. 이 경우 기능 로직에 결함이 있음에도 불구하고 모킹된 데이터로 인해 테스트는 통과하게 되며, 향후 도메인 로직이 변경되더라도 테스트가 실패하지 않아 시스템 내부에 잠재적인 기능적 버그(Functional bugs)를 방치하게 되는 부작용이 발생할 수 있습니다[6, 7].
|
||||
### 매 응용
|
||||
1. Greenfield library — 매 API design 의 test 의 drive.
|
||||
2. Bug fix — 매 reproducing test 먼저 write.
|
||||
3. AI agent — 매 spec → test → impl 매 deterministic loop.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
## 💻 패턴
|
||||
|
||||
#### [관계 유형 A (아키텍처/설계 패턴)]
|
||||
- [[Clean Architecture]]
|
||||
- 연결 이유: TDD와 결합하여 모바일(Flutter) 애플리케이션의 계층(프레젠테이션, 도메인, 데이터)을 분리하고 로직을 보호하는 근간이 됩니다[1-3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: TDD가 프론트엔드 및 모바일 UI에서 비즈니스 로직을 어떻게 효과적으로 분리하고 검증할 수 있게 하는지에 대한 구조적 원리.
|
||||
### Pytest red-green-refactor
|
||||
```python
|
||||
# tests/test_pricing.py
|
||||
import pytest
|
||||
from pricing import discount_price
|
||||
|
||||
- [[Hexagonal Architecture]]
|
||||
- 연결 이유: 백엔드 환경에서 TDD를 적용할 때, 외부 의존성을 배제하고 비즈니스 로직을 독립적으로 테스트할 수 있도록 포트(Ports)와 어댑터(Adapters)로 시스템을 분리하는 아키텍처입니다[4, 8, 9].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 데이터베이스나 프레임워크에 의존하지 않는 순수 도메인 로직 테스트의 중요성과 구현 방법.
|
||||
def test_no_discount_for_zero_qty():
|
||||
assert discount_price(100, qty=0) == 100
|
||||
|
||||
#### [관계 유형 B (구현/활용 도구)]
|
||||
- [[Mockito]]
|
||||
- 연결 이유: Spring Boot 등의 백엔드 TDD 환경에서 실제 DB 대신 비즈니스 로직을 독립적으로 검증하기 위해 사용되는 대표적인 모킹 도구입니다[4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: TDD에서 인프라 계층을 격리하는 방법과 모킹 오용으로 인한 잠재적 버그 발생(Mocking Caveat)의 원리[5, 7].
|
||||
|
||||
- [[In-Memory Database]]
|
||||
- 연결 이유: 백엔드 로직 테스트 시 실제 DB를 대체하여 TDD 환경 구축을 용이하게 하는 도구(예: H2)입니다[4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 모킹(Mocking) 도구의 대안으로서 데이터 영속성 테스트를 빠르고 격리된 상태에서 수행하는 방법.
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- TDD 과정에서 모킹(Mocking)을 과도하게 사용할 때 발생하는 기능적 결함 은폐 문제(Mocking Caveat)를 방지하기 위한 대안적 테스트 전략은 무엇인가?
|
||||
- Flutter의 클린 아키텍처와 Spring Boot의 육각형 아키텍처 환경에서 TDD를 적용할 때, 도메인 계층 격리 방식의 차이점은 무엇인가?
|
||||
- 상태 관리 패턴(예: Flutter의 BLoC)이 TDD 기반의 비즈니스 로직 검증을 어떻게 더 용이하게 만드는가?
|
||||
- GitHub Copilot과 같은 AI 도구를 활용한 '단위 테스트 자동 생성' 기능이 전통적인 TDD 워크플로우(Test-First)를 어떻게 변화시킬 수 있는가?
|
||||
- 테스트 시 실제 DB 연동, In-Memory DB 사용, Mockito 사용 등 각 인프라 추상화 방식이 갖는 성능 및 검증 신뢰도 측면의 차이는 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 실제 애플리케이션 코드를 구현하기 전, 요구사항을 바탕으로 테스트 코드를 먼저 작성하여 기능을 정의하고 신뢰성을 검증합니다[1].
|
||||
- **System Design:** 프론트엔드/모바일에서는 클린 아키텍처, 백엔드에서는 육각형 아키텍처를 도입하여 시스템을 설계함으로써, UI와 인프라로부터 도메인 로직을 분리해 TDD를 쉽게 적용할 수 있는 기반을 마련합니다[1, 2, 4].
|
||||
- **Operation / Maintenance:** 철저한 TDD를 통해 작성된 코드는 변경 사항이 발생했을 때 기존 로직이 망가지는 것을 방지하여, 장기적인 운영 및 유지보수를 용이하게 만듭니다[1].
|
||||
- **Learning Path:** 최신 프레임워크 학습 시 단순히 UI 개발 기술만 익히는 것을 넘어, 도메인/데이터 계층 분리 원리와 TDD를 함께 적용하는 방법을 학습하여 확장성 높은 실전 역량을 갖출 수 있습니다[1, 3].
|
||||
- **My Project Relevance:** 팀 프로젝트나 엔터프라이즈 환경 도입 시, 기능 중심의 모듈화와 더불어 Mockito, In-memory DB를 적극 활용하여 핵심 비즈니스 로직에 대한 견고한 테스트망을 선제적으로 구축할 때 적용됩니다[4].
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[Functional Testing]]
|
||||
- 확장 방향: 단위 테스트 위주의 TDD에서 더 나아가, Cucumber와 같은 도구를 사용해 시스템의 전체 동작과 사용자 시나리오를 기능적으로 검증하는 BDD(Behavior-Driven Development) 영역으로 이해를 확장할 수 있습니다[10].
|
||||
|
||||
- [[AI-driven Test Automation]]
|
||||
- 확장 방향: TDD의 수동 테스트 작성 부담을 줄이기 위해, AI 코딩 어시스턴트(예: GitHub Copilot의 /test 명령어)를 활용한 단위 테스트 코드 자동 생성 및 AI 코드 리뷰 통합 분야를 탐구할 수 있습니다[11, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
---
|
||||
|
||||
- [[Clean_Code]]: TDD의 리팩토링 단계에서 지향해야 할 코드의 표준.
|
||||
- [[Ports_and_Adapters]]: 외부 의존성을 분리하여 TDD를 용이하게 만드는 아키텍처 스타일.
|
||||
- [[Mockito]]: TDD에서 외부 시스템을 격리하기 위해 널리 사용되는 모킹 프레임워크.
|
||||
|
||||
|
||||
## 1. 개요
|
||||
테스트 주도 개발(TDD, Test-Driven Development)은 코드를 작성하기 전에 테스트 케이스를 먼저 작성하고, 이를 통과시키기 위한 최소한의 코드를 작성한 뒤 리팩토링을 거치는 소프트웨어 개발 방법론이다. "실패하는 테스트 작성(Red) -> 테스트 통과(Green) -> 코드 개선(Refactor)"의 짧은 주기를 반복하며, 설계의 품질을 높이고 결함 없는 견고한 코드베이스를 구축하는 것을 목표로 한다.
|
||||
|
||||
## 2. 핵심 사이클 (Red-Green-Refactor)
|
||||
1. **Red (실패하는 테스트 작성)**: 구현하고자 하는 기능의 요구사항을 반영한 실패하는 단위 테스트 작성. 아직 기능이 구현되지 않았으므로 컴파일 에러나 테스트 실패가 발생하는 단계.
|
||||
2. **Green (테스트 통과)**: 테스트를 통과하기 위한 가장 빠르고 간단한 코드 작성. 코드의 품질보다는 테스트 통과라는 목적에 집중.
|
||||
3. **Refactor (코드 개선)**: 테스트를 통과한 상태를 유지하면서 코드의 중복을 제거하고 가독성을 높이며 구조를 개선. TDD를 통해 확보된 테스트망 덕분에 안전한 리팩토링이 가능함.
|
||||
|
||||
## 3. 엔지니어링 가치
|
||||
- **높은 코드 신뢰성**: 모든 코드가 테스트를 거쳐 작성되므로, 버그 발생 확률이 현저히 낮아지며 요구사항이 코드로 정확히 구현되었음을 보장.
|
||||
- **설계 품질 향상**: 테스트하기 쉬운 코드를 작성하려 노력하는 과정에서 자연스럽게 모듈 간의 결합도가 낮아지고 응집도가 높아지는 건전한 설계 유도.
|
||||
- **유지보수 및 리팩토링 용이성**: 완벽한 테스트 커버리지는 기존 기능을 망가뜨릴 걱정 없이 코드를 대담하게 수정하거나 새로운 기능을 추가할 수 있는 심리적 안전망 제공.
|
||||
- **살아있는 문서**: 테스트 코드 자체가 시스템의 사용법과 기대 동작을 설명하는 가장 정확하고 최신화된 기술 문서 역할을 수행.
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **개발 속도의 저하**: 초기 단계에서 테스트 코드를 작성하는 시간이 추가되므로 단기적인 개발 속도는 느려질 수 있음. (장기적으로는 디버깅 및 유지보수 비용 절감으로 상쇄됨)
|
||||
- **모킹(Mocking)의 함정**: 외부 의존성을 격리하기 위해 과도하게 모킹을 사용하면, 실제 연동 시 발생하는 문제를 놓치거나 테스트 코드가 구현 상세에 너무 의존하게 될 위험이 있음.
|
||||
- **테스트 자체의 유지보수**: 비즈니스 로직이 변경될 때마다 테스트 코드도 함께 갱신해야 하며, 잘못 작성된 테스트는 오히려 개발의 발목을 잡는 '깨지기 쉬운 테스트(Fragile Test)'가 될 수 있음.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 소프트웨어의 결함을 사전에 예방하고 지속 가능한 코드 품질을 유지하기 위한 가장 강력한 개발 실천법 및 설계 도구 정립.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
def test_10pct_discount_at_qty_10():
|
||||
assert discount_price(100, qty=10) == 90.0
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
```python
|
||||
# pricing.py — minimum impl after red
|
||||
def discount_price(price: float, qty: int) -> float:
|
||||
if qty >= 10:
|
||||
return price * 0.9
|
||||
return price
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Parametrize
|
||||
```python
|
||||
@pytest.mark.parametrize("qty,expected", [
|
||||
(0, 100), (1, 100), (9, 100),
|
||||
(10, 90), (50, 90), (100, 80),
|
||||
])
|
||||
def test_discount_table(qty, expected):
|
||||
assert discount_price(100, qty=qty) == expected
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Fixture + integration test
|
||||
```python
|
||||
@pytest.fixture
|
||||
def db():
|
||||
conn = sqlite3.connect(":memory:")
|
||||
conn.execute("CREATE TABLE orders (id INT, total REAL)")
|
||||
yield conn
|
||||
conn.close()
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
def test_save_order(db):
|
||||
save_order(db, id=1, total=99.0)
|
||||
row = db.execute("SELECT total FROM orders WHERE id=1").fetchone()
|
||||
assert row[0] == 99.0
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Property-based (Hypothesis)
|
||||
```python
|
||||
from hypothesis import given, strategies as st
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@given(st.floats(min_value=0, max_value=1e6), st.integers(min_value=0, max_value=1000))
|
||||
def test_discount_never_exceeds_price(price, qty):
|
||||
assert discount_price(price, qty) <= price
|
||||
```
|
||||
|
||||
### TypeScript / Vitest
|
||||
```typescript
|
||||
import { test, expect } from 'vitest';
|
||||
import { discountPrice } from './pricing';
|
||||
|
||||
test('10% discount at qty 10', () => {
|
||||
expect(discountPrice(100, 10)).toBeCloseTo(90);
|
||||
});
|
||||
```
|
||||
|
||||
### AI-aided TDD loop (2026)
|
||||
```bash
|
||||
# .claude/commands/tdd.md
|
||||
# 1. Write failing test for: $ARGUMENTS
|
||||
# 2. Run pytest (expect red)
|
||||
# 3. Implement minimum code to pass
|
||||
# 4. Run pytest (expect green)
|
||||
# 5. Refactor; ensure still green
|
||||
# 6. Open PR
|
||||
```
|
||||
|
||||
```python
|
||||
# Claude Code automated loop pseudocode
|
||||
while not all_green:
|
||||
test = agent.generate_test(spec)
|
||||
write_file(test)
|
||||
run_pytest() # expect FAIL
|
||||
impl = agent.generate_impl_to_pass(test)
|
||||
write_file(impl)
|
||||
if run_pytest().passed:
|
||||
agent.refactor()
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 pure function | TDD strict |
|
||||
| 매 UI tweak | Snapshot + visual diff (TDD overkill) |
|
||||
| 매 spike / prototype | Skip TDD, 매 throw away |
|
||||
| 매 bug fix | 매 reproducing test 먼저 |
|
||||
| 매 AI agent task | Test-first prompt — 매 verifiable |
|
||||
|
||||
**기본값**: 매 TDD for business logic + libraries. 매 visual / experimental code 매 skip.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Testing]] · [[Extreme Programming]]
|
||||
- 변형: [[BDD]] · [[Property-Based Testing]] · [[Mutation Testing]]
|
||||
- 응용: [[Refactoring]] · [[CI/CD]] · [[Agent Coding Loop]]
|
||||
- Adjacent: [[pytest]] · [[Vitest]] · [[Hypothesis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 test generation (Claude Code "write tests for X"). 매 stub from spec. 매 reproducing-test from bug report.
|
||||
**언제 X**: 매 LLM의 hallucinate API → 매 test의 wrong. 매 always run + verify red→green.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Test after**: 매 not TDD; 매 confirms current code, 매 design 의 X drive.
|
||||
- **Mock everything**: 매 test의 verify nothing real.
|
||||
- **Brittle tests**: 매 implementation detail 의 lock — refactor breaks.
|
||||
- **Skipping refactor step**: 매 code rot.
|
||||
- **AI-generated test without running**: 매 false-green.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Kent Beck "TDD by Example" 2003; Anthropic Claude Code TDD docs 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — TDD red-green-refactor + property-based + AI agent loop |
|
||||
|
||||
Reference in New Issue
Block a user