[Software Engineering] TDD(Test Driven Development)

TDD(Test Driven Development)

---

TDD(Test Driven Development) 란

 

 

테스트 주도 개발(TDD, Test Driven Development)은 소프트웨어를 개발하는 여러 방법론 중 하나이다. 제품이 오류 없이 정상 작동하는지 확인하기 위해 모든 코드는 프로그래머가 작성 하고 난 후 테스트를 거치게 된다. TDD 방법론에서는 제품의 기능 구현을 위한 코드와 별개로, 해당 기능이 정상적으로 작동하는지 검증하기 위한 테스트 코드를 우선 작성한다. 이를 통하여 테스트가 실패할 경우 테스트를 통과하기 위한 최소한의 코드로 개선한다. 최종적으로 테스트에 성공한 코드를 리팩토링하는 과정을 거치게 된다. 

 

 

* 정리

TDD 란 Test-Driven Development 로 개발(코드 작성)전 테스트 코드를 먼저 작성하는 테스트 주도 개발 방법론을 의미한다.  

 

(1) 딱 하나의 케이스에 대한 테스트 코드 작성 후 테스트가 실패하게 되면(* 기능 구현 전이기에 실패가 당연하다)

(2) 테스트가 통과할 정도의 코드를 작성하여 테스트를 다시 수행하여 성공하도록 만든다. 

(3) 이렇게 하나의 테스트가 완성이 되면 그 다음 기능으로 넘어가서 그 기능에 해당하는 테스트 코드를 작성하여 위의 과정을 반복하게 된다. 

(4) 모든 기능 구현이 완료되었다면, 즉 모든 테스트 코드를 통과했다면 코드의 퀄리티 개선을 위하여 리팩토링을 진행하게 된다.

 

---

TDD 개발 방식의 장점

 

1. 보다 튼튼한 객체 지향적인 코드 생산

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

 

2. 재설계 시간 단축

테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야 하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해 볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

 

3. 디버깅 시간 단축

TDD의 경우 자동화 된 유닛 테스팅을 전제하므로 특정 버그를 손 쉽게 찾아낼 수 있다. 

 

4. 테스트 문서의 대체 가능

주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출 할 수 있다. 

 

5. 추가 구현의 용이함

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다. 

 

---

TDD 개발 방식의 단점

생산성 저하

위와 같은 수 많은 장점을 가진 TDD 방법론이지만 모두가 이 개발 프로세스를 따르는 것은 아니다. 그 이유는 바로 생산성 저하 문제 때문이다.  TDD 개발 프로세스를 따르게 되면  처음부터 2개의 코드를 짜야 하고 중간중간 테스트를 하면서 고쳐 나가야 한다. 이러한 이유 때문에 일반적인 개발 프로세스에 비하여 대략 10~30% 의 개발시간이 추가적으로 소요가 되게 되며 SI 프로젝트에서는 품질보다는 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.