TDD란?
TDD란 Test Driven Development의 약자로, ‘테스트 주도 개발’이라고 한다.
짧은 주기의 반복 테스트를 이용한 소프트웨어 방법론이다.
애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 설계를 중요시 한다.
eXtream Programming(XP)
: 고객의 요구 사항에 유연하게 대처하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법
TDD 개발 주기
Red-Green-Refactor
- Red: 실패하는 테스트 코드 작성
- Green: 테스트가 통과하는 코드 작성
- Refactor: 중복 코드 제거, 일반화 등 리팩토링 수행
일반적인 개발 방식 vs. TDD 개발 방식
일반적인 개발 방식
- 요구사항 분석 → 설계 → 개발 → 테스트 → 배포
- 고객의 요구사항은 변경될 가능성이 있어 초기에 완벽한 설계 불가능
- 추가적인 요구사항이나 잠재적인 버그 등으로 인해 재설계를 진행하면서 불필요한 코드 발생
- 이는 코드의 재사용성을 떨어트리고, 유지보수를 어렵게 만듦(소스코드 품질 저하)
- 작은 수정에도 모든 기능을 테스트하게 되면서 자체 테스트 비용 증가
TDD 개발 방식
- 테스트 코드 작성 → 개발 → 리팩토링 사이클 반복
- 설계 단계에서 프로그래밍의 목적을 반드시 정의하고, 무엇을 테스트할지 미리 정의해야 함
- 테스트 도중 발생하는 예외 사항(추가 요구사항, 버그 등)을 테스트 케이스에 추가하고 설계 개선
- 위 반복 단계가 진행되면서 자연스럽게 버그가 줄고, 소스코드는 간결해짐(소스코드 품질 향상)
- 지속적인 테스트 코드 작성으로 추가적인 요구사항이 생겨도 재설계 시간이 절약됨
JUnit(Java)
대표적인 TDD Tool로 ‘Java에서 독립된 단위테스트를 지원해주는 프레임워크’이다.
어노테이션 기반으로 테스트를 지원하며, 단정문(Assert)으로 테스트 케이스의 기대값에 대해 수행 결과를 확인한다.
c.f.) xUnit 프레임워크: JUnit(Java), CUnit(C), PyUnit(Python) 등
TDD의 장단점
TDD의 장점
1. 디버깅 시간 단축
단위 테스트의 장점이다.
단위 테스트 코드가 없다면 특정 버그가 어디서 발생했는지 찾기 위해 모든 레이어를 디버깅해야 하지만, TDD의 경우 자동화된 단위 테스트를 통해 버그를 쉽게 찾을 수 있다.
2. 코드의 재사용성 증가
Red 단계에서 버그와 같은 예외 사항이 미리 고려되고 테스트가 통과된 코드만 개발 단계에서 사용된다.
불필요하거나 중복이 발생한 코드는 정리되고, 재사용성이 높고 유지보수가 용이한 코드만 남는다.
3. 재설계 시간 단축
테스트 코드를 미리 작성하기 때문에 프로그래밍의 목적을 분명하게 할 수 있다.
테스트 코드를 작성하면서 다양한 예외 사항을 생각해볼 수 있기 때문에 개발을 진행하면서 설계가 변경되는 일을 방지할 수 있다.
4. 빠른 피드백
인수 테스트는 거의 완성된 코드를 가지고 사용자의 관점에서 사용할 수 있는 수준인지를 확인한다. 이 과정에서 문제를 발견해도 정확한 원인 파악이 어렵다.
TDD는 기능 단위로 테스트를 진행하기 때문에 코드가 완성되어 프로그래머의 손을 떠나기 전에 피드백을 받는 것이 가능하다.
5. 불안정성을 제거하여 생산성 향상
켄트 벡은 TDD는 불안함을 지루함으로 바꾸는 마법의 돌이라고 말한 적이 있다.
코드가 지닌 불안정성과 불확실성을 지속적으로 해결하여 생산성을 높인다.
6. 추가 구현 용이
기존 코드에 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다.
하지만 TDD의 경우 자동화된 단위 테스트를 통해 테스트 시간을 단축할 수 있다.
7. 문서 대체 기능
테스트를 작성할 때 어떤 의도를 가지고 테스트 코드를 작성하였는지, 그리고 어떤 결과 값을 기대하는지를 작성하기 때문에 코드를 작성한 사람의 의도를 파악할 수 있다.
TDD의 단점
1. 개발 시간 증가
단기적으로 봤을 때 코드 개발 시간이 증가한다.
개발자에게 테스트 코드 작성이 익숙하지 않을 수도 있고, 기존에 비즈니스 코드만 작성하고 넘어갔을 때에 비해 테스트 코드를 작성하는데 들이는 시간이 많다.
2. 구조에 얽매임
테스트는 테스트일 뿐이고 실제 코드가 더 중요한데, TDD 원칙 때문에 쉽게 넘어가기 못하는 경우가 발생한다.
BDD, DDD
BDD
BDD는 Behevior Driven Development의 약자로 ‘행동 주도 개발’이다.
TDD에서 파생된 개발 방법론으로 사용자 또는 비즈니스 요구사항을 행위와 시나리오를 중심으로 한다.
개발자와 비개발자 모두 이해하기 쉬운 자연어로 표현하여 의사소통을 원활히 하고, 요구사항을 명확하게 전달하고 구현한다.
Given-When-Then 형태로 표현하여 주어진 상황에서 어떤 동작을 하고 기대하는 결과가 나오는지를 명시한다.
Given-When-Then
- Given(주어진 상황): 초기 상태나 전제 조건 기술
- When(행동): 수행할 동작이나 이벤트 기술
- Then(결과): 예상되는 결과나 상태 기술
DDD
DDD는 Domain Driven Design의 약자로 ‘도메인 주도 설계’로, 기존 데이터 중심의 접근법에서 벗어나 도메인 패턴을 중심에 두고 설계하는 방식이다.
보편적인(ubiquitous) 언어를 사용한다. 도메인 전문가와 커뮤니케이션 문제를 없애기 위해 동일한 표현과 단어로 구성된 단일 언어체계를 구축하여 사용한다.
소프트웨어 엔티티와 도메인 컨셉을 가장 가까이 일치시킨다. 도메인 모델부터 코드까지 함께 움직이는 모델을 지향한다.
참고
https://tidyfirst.substack.com/p/tdd-isnt-design
https://f-lab.kr/insight/importance-of-tdd-and-ddd-in-modern-development
