Wikify: Auto-consolidate redundant/similar knowledge base files
This commit is contained in:
Antigravity Agent
@@ -1,14 +1,13 @@
|
||||
---
|
||||
category: Unified
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
title: Test-Driven Development
|
||||
description: "Test-Driven Development(TDD)는 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 애플리케이션의 로직을 검증하는 소프트웨어 개발 패턴입니다[1]."
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# Test-Driven Development
|
||||
|
||||
## 📌 Brief 실용 Summary
|
||||
## 📌 Brief Summary
|
||||
Test-Driven Development(TDD)는 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성하여 애플리케이션의 로직을 검증하는 소프트웨어 개발 패턴입니다[1]. 프레임워크별 실전 설계 패턴에서 TDD는 비즈니스 로직을 외부 인프라나 UI로부터 독립시켜 철저히 테스트함으로써, 시스템의 신뢰성과 유지보수성을 극대화하는 핵심적인 역할을 수행합니다[1, 2]. 주로 클린 아키텍처나 육각형 아키텍처와 결합하여 모듈화되고 확장 가능한 시스템을 구축하는 데 활용됩니다[3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
@@ -28,7 +27,6 @@ Test-Driven Development(TDD)는 실제 코드를 작성하기 전에 테스트
|
||||
비즈니스 로직을 독립적으로 테스트하기 위해 Mockito 등의 모킹 프레임워크를 과도하게 사용할 경우, 도메인의 기능적으로 잘못된 동작을 테스트 코드 내에 하드코딩하게 될 위험이 있습니다[5, 6]. 이 경우 기능 로직에 결함이 있음에도 불구하고 모킹된 데이터로 인해 테스트는 통과하게 되며, 향후 도메인 로직이 변경되더라도 테스트가 실패하지 않아 시스템 내부에 잠재적인 기능적 버그(Functional bugs)를 방치하게 되는 부작용이 발생할 수 있습니다[6, 7].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
|
||||
#### [관계 유형 A (아키텍처/설계 패턴)]
|
||||
@@ -74,4 +72,35 @@ Test-Driven Development(TDD)는 실제 코드를 작성하기 전에 테스트
|
||||
- 확장 방향: TDD의 수동 테스트 작성 부담을 줄이기 위해, AI 코딩 어시스턴트(예: GitHub Copilot의 /test 명령어)를 활용한 단위 테스트 코드 자동 생성 및 AI 코드 리뷰 통합 분야를 탐구할 수 있습니다[11, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
*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
|
||||
- **검토 이유**: 소프트웨어의 결함을 사전에 예방하고 지속 가능한 코드 품질을 유지하기 위한 가장 강력한 개발 실천법 및 설계 도구 정립.
|
||||
Reference in New Issue
Block a user