TDD(Test Driven Development)는 테스트 주도 개발이라고도 불리며, 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. TDD를 적용해 개발을 진행할 경우, 우선 작은 단위의 테스트 케이스를 작성한 뒤 이를 통과하는 코드를 추가하는 과정을 반복하게 된다.
한 마디로, 테스트 코드를 먼저 작성하고 이를 통과하기 위한 코드를 작성해나가는 개발 방식 이라고 할 수 있다.
일반적인 개발 방식은 요구사항 분석 > 설계 > 개발 > 테스트 > 배포 형태의 주기로 이루어진다.
이러한 방식은 아래와 같이 몇 가지 위험요소를 가지고 있다.
사용자의 요구사항이 명확하지 않거나 변경될 경우 재설계가 필요한데, 이러한 과정에서 불필요하거나 중복되는 코드가 남아 유지보수가 어려운 코드가 될 수 있다.
작은 단위의 기능 추가/수정에도 전체적인 테스트가 필요하므로 테스트 비용이 증가하고 버그 검출이 어려울 수 있다.
TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다. TDD 개발 방식은 아래와 같이 Red > Green > Yellow 단계별 프로세스로 진행된다.
🔴 Red단계 : 테스트 실패
🟢 Green단계 : 테스트 성공
🟡 Yellow단계 : 리팩토링
버그와 같은 예외 사항은 Red 단계에서 우선적으로 고려되어 개선되는 방향으로 설계된다. 이후 테스트가 통과된 코드만 개발 단계에서 사용되므로, 불필요하거나 중복되는 코드가 정리된 재사용성이 높고 유지보수가 용이한 코드가 남는다.
개발자는 Red단계에서 다양한 예외사항을 미리 고려해가며 테스트 코드를 작성한다. 이런 시간은 개발자가 실제 개발 단계에서 모든 개발 방향을 다시 재설계하게되는 가능성을 줄여준다.
TDD는 유닛테스팅을 통해 개발을 진행하므로 특정 버그가 어디의 문제에서 비롯된 것인지 쉽게 찾아낼 수 있다. TDD의 장점이라기보다는 유닛테스팅의 장점이라고도 볼 수 있다.
기존 코드에 새로운 기능을 추가하려 할 때 가장 우려되는 점은 추가하려는 기능이 기존 코드에 어떤 영향을 줄지 정확히 알지 못한다는 것. 하지만 TDD로 개발했을 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.
앞서 여러가지 장점을 나열했지만 현업에서 TDD가 적용되어야 하는지에 대해서는 논란이 있고, 실제로 잘 사용되지 않는다. 그 치명적인 단점은 아래와 같다.
기존의 개발 프로세스에 테스트 케이스 설계까지 추가되어야 하니 코드 생산 비용이 높아진다는 의견이 많다. 기업별로 테스트를 어떻게 진행할 것이며, 각각의 프로젝트 성격에 따른 테스트 프레임워크 등 여러 부분을 고려해야 하는 것도 코드 생산성을 저하시키는 요인이 될 수 있다.
위 단점과 연결되는 이야기이지만, 많은 기업들은 전체적인 개발 시간을 줄이는 것보다는 단기적인 기간에 맞추어 성과를 내도록 개발을 진행하기 때문에 TDD 도입이 어렵다.
📌 참고 학습자료
위키백과 - 테스트주도개발
TDD란? 테스트주도개발에 대한 편견과 실상, 방법론
[Agile] TDD(테스트 주도 개발)란