TDD란 Test Driven Devlopment의 약자로 '테스트 주도 개발'이다.

일반적으로 무언가 개발할 때의 순서는 다음과 같다.

디자인 -> 코드 개발 -> 테스트

테스트까지 마친 후 수정해야할 사항이 있다면 다시 처음으로 돌아가 같은 과정을 반복한다.

그러나 TDD는 다음과 같은 과정을 따른다.

디자인 -> 테스트코드 작성 -> 코드 개발

기존의 방법과 달리 테스트코드를 먼저 작성한다. 이에 따라 달라지는 점은 설계/디자인 자체를 고칠 때는 위와 같지만 코드 개발을 할 때 실시간으로 테스트를 해볼 수 있다는 장점이 있다.

어떤 상황에서 사용하나?

만약 내가 혹은 팀이 여러 번 해본 작업이고 방법과 결과를 대부분 알고 있다면 굳이 TDD를 하지 않아도 된다.
반대로 아래와 같은 상황에서 사용하는 것이 좋아 보인다.

1. 처음해보는 프로그램 주제

• 나에 대한 불확실성이 높은 경우

2. 고객의 요구조건이 바뀔 수 있는 프로젝트

• 외부적인 불확실성이 높은 경우

3. 그외에 개발 도중 코드를 많이 수정해야 할 경우
4. 내가 개발하고 나서 그 프로젝트를 모르는 누군가 참여하게 되는 경우

결론은 개발 과정, 결과를 내가, 또는 다른 누군가가 알지 못하는 경우가 있을 때 사용한다.

TDD 장점

1. 객체지향적인 코드 생산

• TDD는 코드의 재사용성을 보장하므로 기능 별 철저한 모듈화가 이루어진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 해 필요에 따라 모듈을 추가하거나 제거해도 전체 구조에 큰 영향을 미치지 않게 된다.

2. 재설계 시간의 단축

• 테스트 코드를 먼저 작성하기 때문에 개발자가 무엇을 해야하는지 명확히 안 후에 개발을 진행하게 된다. 또한 테스트 코드를 작성하면서 다양한 예외 경우를 생각해 볼 수 있다.

3. 디버깅 시간의 단축

• 유닛 테스트의 장점이기도 하다. 예를 들어 사용자의 데이터가 잘못 나온다면 db의 문제인지, 비즈니스 레이어의 문제인지, 또는 다른 부분의 문제인지 자동화된 유닛테스팅을 이용해 쉽게 버그를 찾을 수 있다.

4. 테스트 문서 / api 명세 대체

• 어떤 요소들이 테스트 되었는지 명시한 테스트 정의서, 또는 api 명세서를 미리 작성한 테스트 코드가 대체할 수도 있고 최소한 테스트 코드를 기반으로 쉽게 작성할 수 있다.

TDD 단점

• 가장 큰 단점은 생산성의 저하이다. 개발 속도가 느려진다고 생각하는 사람도 많다. 처음부터 2개의 코드를 짜야하고(테스트코드), 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다. TDD 방식은 일반적인 개발 방식에 비해 10~30% 정도 시간이 더 걸린다고 한다.
• 위와 같은 이유로 초기 비용이 확실히 더 든다. 빠르게 개발이 필요한 상황이라면 적합하지 않을 수 있지만, '초기 비용'보다 '유지보수 비용'이 더 중요한 경우라면 TDD를 사용하는 것이 더 좋을 것이다.