TDD(Test- Driven Development)에 대하여

흔히 테스트 주도 개발이라고 하는 이 개념은 짧은 개발 사이클을 반복하여 소프트웨어를 개발하는 방법론이다.

 

개념 자체는 이전부터 있었거나 개발되었을 수 있으나 공식적으로는 Kent Beck이라는 사람이 2003년에 개발한 것으로 알려져 있다.

이 TDD에 대해서 좀 더 자세히 알아보자.

 

TDD란 이름에서 알수 있듯 이 방법론은 테스트가 주를 이루게 된다.

 

흔히들 폭포수 모델이라고 하는 이 개발 방식을 한번 보자.

r이 짤렸네...

일반적인 개발 방식은 그림처럼 요청 ->설계 -> 개발 -> 테스트 -> 배포 -> 유지보수 순으로 흘러가지만, 이 개발 방식은 다음과 같은 위험성이 있다.

1. 소비자의 요청사항이 애매할 수 있다.

2. 그로 인해 설계가 까다로워진다.

3. 2의 원인으로 인해 테스트 비용이 증가하게 되고,

4. 종합적인 이유로 결과물의 품질이 낮을 수 있다.

 

이러한 문제점을 보면 개발이 쉽지 않다는 것을 알 수 있다.

한편, TDD방식으로 개발은 어떻게 진행될까?

 

TDD개발방식은 요청 -> 설계 단계까지는 동일하나 개발 단계에서 테스트 코드를 먼저 만들어 본다는 점이 가장 큰 차이점이다.

 

설계를 하고 테스트 코드를 작성해보고, 잘 작동하지 않는다면 설계를 다시 해보는 것이다. 중요한 것은 이 사이클이 전체 코드의 일부분만을 대상으로 시행되어야 한다는 것이다. 각각의 최소단위를 테스트코드로 만들어서 시험을 한다는 것이 이 TDD 방법론의 핵심이라고 할 수 있다.

 

TDD 방식의 장점은 앞서말했듯 모듈식으로 구조가 짜여져 있어 테스트 과정에서 특정 부분을 교체한다고 해도 쉽게 구조의 변경이 가능하다는 점이다. 뿐만 아니라 최소 단위로 개발을 시행하기 때문에 재설계 과정에서 드는 시간 또한 단축된다.

 

물론 TDD 방식의 개발방식이 장점만 있는 것은 아니다. TDD 방식의 개발은 필연적으로 코드를 두 번 짜야 하고, 중간중간 테스트를 해나가면서 고쳐야 하기 때문에 생산성의 저하가 있을 수 있다.