TDD란?
Test Driven Development의 약자로 '테스트 주도 개발'이라고 부른다. 이 방법론은 켄트 벡(Kent Back)에 의해 처음 소개됐다.
TDD는 소프트웨어 개발 방법론 중 하나로, 작은 단위의 테스트 코드를 먼저 작성한 후 그에 맞게 기능을 구현하는 방식이다.
또한, 짧은 시간 안에 여러 번 반복하여 개발하는 프로세스이며, 애자일(Agile) 방법론 중 하나인 XP(Extreme Programming)의 Test-First 원칙을 구체화한 방법론이다.
Test-First는 XP의 원칙 중 하나로, 개발자가 기능을 구현하기 전에 먼저 테스트 코드를 작성하여 요구사항을 명확히 하고, 이를 기반으로 코드를 작성하여 즉각적인 피드백을 받는 접근 방식이다.
TDD 개발 주기
TDD의 개발 주기는 위의 그림과 같이 크게 세 단계로 구성되어 있다.
🔴 Red (테스트 실패)
Red 단계는 요구사항에 맞게 실패하는 테스트 코드를 작성한다. 이 테스트 코드는 아직 기능이 구현되지 않았기 때문에 처음에는 당연히 실패해야 한다.
그리고 작성한 테스트 코드를 실행하여 실패하는 것을 확인한다. 이 과정은 요구사항의 명확성, 테스트의 정확성, 그리고 개발 환경의 안정성을 확보하기 위한 과정이다.
🟢 Green (테스트 통과)
Red 단계에서는 테스트 코드를 작성했다면, Green 단계에서는 테스트 코드를 통과할 수 있는 최소한의 기능을 구현한다. 이때 중요한 포인트는 기능이 완벽하게 작동하지 않아도, 테스트 코드를 통과하는 코드를 작성하는 것이다.
그리고 코드를 실행하여 Red 단계에서 작성한 테스트 코드가 통과하는지 확인한다. 만약 테스트가 성공적으로 통과하였다면, 개발자는 기능이 요구사항을 충족하고 있음을 확인할 수 있다.
이 단계에서는 기능이 제대로 구현되었다는 것을 확인하는 단계이기 때문에, 코드의 품질이나 구조에 대한 고민은 최소한으로 해도 된다.
🔵 Refactor (리팩토링)
모든 테스트를 통과하였다면 이제 코드를 리팩토링하여 가독성, 유지 보수성, 성능 등을 개선할 차례이다. 이 과정에서는 불필요한 코드나 중복된 코드를 제거하고, 더 나은 구조를 적용하는 것이 중요하다.
리팩토링 후에는 반드시 테스트 코드를 다시 실행하여 기존 기능이 손상되지 않았는지 확인한다.
결론
글로 보면 해당 사이클이 길게 느껴질 수 있지만, 실제로는 짧은 반복 주기로 이루어진다. 이러한 사이클은 코드 품질을 향상시키고, 요구사항을 명확히 하며, 빠른 개발 사이클을 통해 지속적인 개선을 가능하게 해준다.
TDD에 대한 고찰
그렇다면 왜 일반적인 개발 방식이 아닌 TDD를 사용해야 하는 것일까? TDD가 무조건적으로 좋은 개발 방법일까? 하나씩 알아보자.
일반 개발 방식과 TDD 개발 방식의 비교
일반 개발 방식
일반적으로 개발 방식은 '요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포'의 형태를 가진다. 이러한 방식은 여러 가지 이점이 있지만, 동시에 개발을 느리게 하는 잠재적 위험이 존재한다.
1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
소비자가 원하는 기능이나 제품에 대한 요구사항이 다양한 이유를 통해 초기 단계에서 명확하게 정의되지 않을 수 있다.
그렇기 때문에 초기에 완벽한 설계가 어려워지며, 프로젝트 진행 중에 요구사항이 변경되거나 추가될 경우, 이를 반영하기 위해 추가 작업이 필요하게 된다.
이러한 점들은 결국 프로젝트의 일정과 비용에 부정적인 영향을 끼치게 된다.
2. 소스코드의 품질이 저하될 수 있다.
일반적인 개발 방식에서는 테스트를 개발 완료 후에 진행함으로, 초기 코드에서 발생한 버그나 문제를 조기에 발견하기가 어렵다. 이는 버그가 나중에 발견될수록 비용이 급격히 증가할 수 있다.
또한 코드가 점진적으로 작성되면서, 수정 사항이 발견될 때마다 일관성이 없거나 일회성으로 작성된 코드는 품질이 떨어지게 된다. 이는 장기적으로 유지 보수에 큰 영향을 끼칠 수 있다.
3. 자체 테스트 비용이 증가할 수 있다.
초기 개발 모델에서는 테스트가 개발 후에 진행되므로, 반복적인 수동 테스트가 발생하게 되고, 시간이 지남에 따라 테스트가 누적되고 관리가 어려워질 수 있다.
또한 요구사항 변경이나 설계 오류로 인해 기능이 수정될 경우, 그에 따라 다시 테스트를 진행해야 하므로, 추가적인 인력과 비용이 소모된다.
문제 발생 원인
이러한 문제점이 발견되는 이유는 어느 프로젝트든 초기 설계가 완벽할 순 없기 때문이다.
프로젝트 설계는 고객의 요구사항 또는 디자인의 오류 등 많은 외/내부 문제에 의해 재설계 되어 점진적으로 완벽한 설계로 나아간다.
TDD 개발 방식
그렇다면 TDD 방식은 어떨까? TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 후 실제 코드를 작성한다는 점이다.
디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다.
테스트 케이스를 작성하는 도중 발생하는 예외 사항(버그 또는 수정사항)은 테스트 케이스에 추가하고 설계를 개선한다. 이후 테스트가 통과된 코드만을 실제 코드로 작성한다.
TDD 개발 방식의 이점
이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해진다. 또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.
TDD 개발 방식의 장단점
그렇다고 TDD 개발 방식이 무조건적으로 좋은 건 아니다. 좋은 것들에는 항상 단점이 존재하기 마련이다.
장점
코드 품질 향상
테스트 코드를 먼저 작성하므로, 코드의 버그를 조기에 발견할 수 있어 수정 비용이 줄어든다.
요구사항 명확화
테스트 코드를 통해 기능의 요구사항이 명확하게 정의되며, 개발자는 이를 기반으로 코드를 작성할 수 있게 된다.
또한 요구사항이 변경될 경우, 테스트 코드를 업데이트하여 요구사항에 일관성을 유지할 수 있다.
보다 튼튼한 객체 지향적인 코드 생산
TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다.
이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며, 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다는 장점이 있다.
추가 구현의 용의함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다.
하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.
단점
생산성 저하
처음부터 2개의 코드를 짜야 하고, 중간중간 테스트를 하며 고쳐나가야 하기 때문에 초기 개발 속도가 느려질 수 있다.
복잡한 테스트 관리
요구사항 변경 시 테스트 코드도 함께 수정돼야 하기 때문에, 테스트 코드 관리가 복잡해질 수 있다.
또한 코드 변경이 잦은 경우 필요 없는 테스트가 늘어나고, 이를 관리하기 위한 추가 작업이 필요할 수 있다.
TDD의 도구 xUnit
xUnit은 TDD의 가장 대표적인 도구이다. xUnit의 시초는 JUnit으로 JUnit은 현재 전 세계적으로 가장 널리 사용되는 'Java 단위 테스트 프레임워크' 이다.
이러한 JUnit을 바탕으로 CUnit(C언어), CppUnit(C++), PyUnit(Python) 등 다양한 xUnit 프레임워크가 탄생하게 되었다.
TDD는 이러한 xUnit을 사용하여 테스트 코드 작성과 자동화를 지원 받는다.
참고자료
