TDD (Test-Driven Development) - 테스트 주도 개발

TDD (Test-Driven Development) - 테스트 주도 개발

TDD는 테스트 코드를 먼저 작성을 하고 프로그램 코드를 작성하는 과정을 말한다.

 

TDD 프로세스는 다음과 같은 3가지 단계로 나눌 수 있다.

• RED (테스트 실패)
  • 구체적인 하나의 기능에 대한 하나의 테스트를 추가하고, 테스트가 실패하는지 확인하는 단계.
  • 테스트가 실패를 해야 해당 테스트가 신뢰성이 있다고 볼 수 있다.
  • 다만, 실패한 이유가 테스트 코드의 문제가 아니여야 한다.
• GREEN (테스트 성공)
  • 모든 테스트에 대해서 코드가 성공을 하도록 코드를 수정하는 단계.
  • 테스트 성공을 위해서 최소한의 코드 변경이 이뤄져야한다.
  • 그 이유는 필요 이상으로 코드가 변경이 된다면 다른 단계에서 악영향을 끼칠 수 있기 때문이다.
• REFACTOR (리팩토링)
  • 코드 베이스를 정리하고, 가독성과 적용성 및 성능을 고려해서 구현 설계를 개선한다.

TDD 방법론을 통해서 개발을 진행하게 되면 이 세가지를 반복을 한다.

출처 : https://ebbnflow.tistory.com/271

 

 

(1) TDD의 장점

1. 보다 튼튼한 객체 지향적인 코드를 생산
   • TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다.
   • 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 한다.
   • 또한 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않는다.
2. 재설계 시간의 단축
   • 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야할지 분명히 정의하고 개발을 시작하게 된다.
   • 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다.
   • 개발 진행 중에 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.
3. 디버깅 시간의 단축
   • 자동화 된 유닛테스팅을 전제하므로 특정 버그를 손 쉽게 찾아낼 수 있다.
4. 테스트 문서의 대체 가능
   • 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
5. 추가 구현의 용이함
   1. 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

 

(2) TDD 단점

• 생산성의 저하
  • 처음부터 2개의 코드를 짜야하고, 중간중간에 테스트를 하면서 고쳐나가야 한다.
  • TDD 방식의 개발 시간은 일번적인 개발 방식에 비해서 대략 10 ~ 30% 정도로 늘어난다.