Antigravity Agent
2.5 KiB
2.5 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | tags | raw_sources | last_reinforced | github_commit | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P-REINFORCE-WIKI-DEV-TDD | 테스트 주도 개발 (Test-Driven Development, TDD) | 10_Wiki/💻 Topics_Dev | verified |
|
A | 1.0 |
|
|
2026-05-02 |
테스트 주도 개발 (Test-Driven Development, TDD)
1. 개요
Test-Driven Development(TDD)는 실제 구현 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 애플리케이션의 로직을 검증하고 설계를 발전시키는 소프트웨어 개발 방법론이다. 'Red(실패하는 테스트) - Green(테스트 통과) - Refactor(리팩토링)' 사이클을 통해 시스템의 신뢰성과 유지보수성을 극대화한다.
2. 핵심 원칙
- 테스트 우선 (Test-First): 요구사항을 만족하는 최소한의 테스트 코드를 먼저 작성.
- 도메인 격리: 비즈니스 로직을 외부 인프라(DB, UI)로부터 분리하여 독립적으로 검증.
- 반복적 정제: 테스트를 통과한 후 코드를 정제(Refactoring)하여 코드 품질을 지속적으로 관리.
3. 프레임워크별 실전 적용
- 모바일 (Flutter): 클린 아키텍처와 결합하여 Domain 계층의 유스케이스를 BLoC 등과 분리해 테스트.
- 백엔드 (Spring Boot): 육각형 아키텍처를 기반으로 Mockito(모킹)나 H2(인메모리 DB)를 활용해 도메인 로직 검증.
4. 트레이드오프 및 주의사항
- 장점: 높은 코드 신뢰성, 설계 개선, 회귀 버그(Regression) 방지.
- 단점 (Mocking Caveat): 과도한 모킹 사용 시 도메인의 기능적 결함을 은폐하거나 테스트 코드 자체가 구현에 강결합될 위험. (기능 결함에도 불구하고 테스트는 통과하는 현상 방지 필요)
5. 지식 연결 (Related)
- Clean_Architecture: TDD를 수행하기 위한 구조적 토대.
- Hexagonal_Architecture: 외부 의존성을 배제하고 도메인을 테스트하기 위한 아키텍처.
- Code_Review_Methodology: 작성된 테스트와 코드의 품질을 교차 검증하는 과정.
🧪 검증 상태 (Validation)
- 정보 상태: 검증 완료 (Verified)
- 출처 신뢰도: A
- 검토 이유: 안정적인 코드베이스 유지를 위한 핵심 공학적 실천 방안 정립.