TDD (Test Driven Development) 의 의미
TDD란 Test Driven Development의 약자로, 테스트 주도 개발이라고 한다. 개발자라면 TDD로 개발해야 효율성이 좋다라는 말을 많이 들어봤을 것이다. 여러 소프트웨어 방법론 중 하나로, 작은 단위의 테스트를 작성하고 이에 대하여 테스트를 통과하는 코드를 만들어 프로그램을 완성시켜나가는 방법이다. 이해하기 쉽도록 아래의 그림을 살펴보자.
1. Red 단계
- 자신이 구현하고자 하는 프로세스에 대해
실패하는 테스트 코드를 작성한다. - 실패할 때까지 작은 단위의 프로세스에 대한 테스트 코드를 작성하는 단계이다.
2. Green 단계
- 테스트를 통과하기 위한
최소한의 코드를 작성한다. - 가능한 빠르게 작성한다. (클린코드에 대한 신경은 전혀 쓰지 않는다.)
3. Yellow 단계
- Green 단계에서 작성한 코드에 대한
리팩토링을 진행한다. - 예를 들면 중복 코드 제거, 일반화, 도메인 모델에 대한 검증 함수 추가가 있다.
테스트 주도 개발을 할 때의 유의점
실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는다.- Green 단계에서는 Red 단계에서 작성한 테스트 코드를 통과할 정도의
최소한의 코드만 작성한다.
위에서 설명한 사이클을 반복하고 나면 어느새 완성되어 있는 코드를 확인할 수 있다.
왜 TDD 인가?
1. 개발에 대한 용기를 얻을 수 있다.
테스트 주도 개발을 이용하면 코드가 에러 나는 것에 대한 두려움 없이 개발을 할 수 있다. Red 단계에서는 오히려 실패하는 테스트 코드를 작성하기 때문에 시작부터 실패를 맛보면서 개발을 시작한다. 나 또한 일반 개발 단계에서는 코드를 완성 시키고 나서 Run버튼을 눌러 빌드하는 것에 대한 약간의 두려움을 가지고 있다. 컴파일 에러가 발생하면 디버깅을 통해 코드를 고칠 수 있지만 애초에 실패한다는 것에 무서움(?)을 가지고 있는 것이다. 그러나 테스트 주도 개발을 알고 나서는 이러한 무서움이 사라졌다. 당연히 실패를 해야하는 코드이기에, 그저 코드가 돌아가게 만들면 그만이기에 코드 작성 속도도 빨라지고 고민하는 시간도 줄어들었다.
2. 버그가 줄어든다.
테스트 주도 개발과 일반적인 개발의 가장 큰 차이점은 테스트 코드를 먼저 작성한다는 점이다. 즉, 모든 기능 단위의 유닛에 대한 테스트 코드가 존재하고 위에서 설명한 사이클의 반복으로 자연스럽게 버그가 줄어든다. 또한, 기능을 수정할 때에도 기능에 대한 테스트 코드가 존재하기에 개발자로서 확신을 가지고 수정할 수 있어 유지보수 측면에서 높은 생산성을 가지게 된다.
3. 재설계 시간을 단축시킨다.
테스트 코드를 작성하면서 발생하는 예외사항에 대해 체크해볼 수 있다. 즉, 실제 코드를 작성하기 전에 예외 사항을 체크할 수 있어 나중에 발생하는 예외 발생 가능성을 낮추어 재설계 시간을 단축시킨다.
4. 기능 추가에 대한 자신감을 가진다.
테스트 주도 개발은 일반적인 개발과 달리 자동화된 유닛 테스팅을 전제로 하여 개발을 한다. 따라서 새로운 기능을 추가할 때에 기존 코드에 어떤 영향을 주는지 한번에 확인이 가능하고, 따라서 쉽게 기능 추가를 할 수 있다.
왜 TDD를 선호하지 않는가?
위와 같은 여러 장점에도 불구하고 TDD를 선호하지 않는 그룹이 많다. 그 이유를 살펴보자.
1. 코드 작성 시간이 길어진다.
테스트 주도 개발의 가장 큰 단점은 실제 코드를 작성하기 전에 2단계의 코드 작성이 필요하다는 것이다. 일반적인 개발 단계에서는 원하는 코드를 바로 작성하여 리팩토링 과정을 거치지만 테스트 주도 개발은 테스트 코드를 작성하고, 그에 대한 실제 코드를 완성도가 낮게 개발하며, 그제서야 리팩토링을 하여 완성도를 높게 만든다. 개발 속도 또한 개발자로서 가져야 하는 중요한 속성이기에 많은 개발자들이 아직 테스트 주도 개발을 하는 것을 꺼려한다.
2. 개발 방식의 변화를 주는게 어렵다.
처음부터 테스트 주도 개발을 통해 프로그램을 설계한 개발자가 아니라면 일반적인 개발 단계를 바로 테스트 주도 개발로 바꾸는 것은 매우 어렵다. 프로그램 설계 방식 또한 개발자의 습관 같은 것이므로 그동안 유지해왔던 방법을 배제하고 쉽게 다른 방법으로 넘어 가기란 쉽지 않다. 오히려 개발을 많이 경험하지 못한 초보(?)개발자에게는 테스트 주도 개발로 시작하는 것이 더 쉬울 것이라 생각한다.
3. 사이클에 갇힐 수 있다.
테스트 주도 개발 단계는 위에서 설명한대로 총 3단계의 과정을 반복하게 된다. 이러한 단계가 애초에 설계된 상태로 개발을 시작하면 중간에 단계를 벗어나기 위한 예외가 발생하여도 쉽게 돌아가지 못하게 된다. 원칙을 깰 수 없는 개발자로서는 실제 코드가 아닌, 단순히 테스트 코드를 작성하는 단계에서도 고민 거리가 추가되는 것이다.
마치며
앞으로 테스트 주도 개발에 대한 시리즈를 만들어 글을 작성할 계획이다. 테스트 주도 개발을 직접 하는 것부터 시작하여 일반적인 개발을 하는 것과의 속도 차이, 단점 극복을 위한 방법 등등 TDD에 대해 좀 더 자세히 파보는(?) 시간을 가질 것이다.
