TDD(Test Driven Development)?

• 반복 테스트를 이용한 S/W 방법론
• 짧은 주기의 반복에 의존하는 개발 프로세스
• 애자론 방법론(eXtream Programming)의 'Test-First'개념에 기반을 둔 단순한 설계를 중심

Extream Programming(XP)

• 미래에 의한 예측을 최대한 하지않고 지속적으로 프로토타입을 완성
• 추가 요구사항 => 실시간 반영

단위 테스트(unit Test)

• class만을 테스트

TDD 개발주기

• {Red}
  • 실패하는 테스트 코드를 먼저 작성
• {Green}
  • 테스트 코드를 성공시키기 위한 실제 코드를 작성
• {Blue}
  • 중복 코드 제거, 일반화 등의 리펙토링을 수행
• 실패하는 테스트 코드를 작성할 때까지 실제코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성 => 실제 코드에 대해 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할수 있고, 정확한 요구사항에 집중

일반 개발 방식과 TDD 개발방식의 비교

일반 개발 방식

일반적인 개발방식

'요구사항분석 -> 설계 -> 개발 -> 테스트 -> 배포'

단점 : 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재

1. 소비자의 요구사항이 처음부터 명확하지 X
2. 처음부터 완벽한 설계는 어려움
3. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하
4. 자체 테스트 비용이 증가

재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처 될 가능성이 크다.

결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워서 유지보수를 어렵게 만든다.

TDD 개발방식

일반적인 개발방식의 차이점

• 테스트 코드를 작성한 뒤에 실제 코드를 작성
• 디자인(설계)단계에서 프로그래밍 목적을 반드시 미리 정의
• 테스트 해야 할지 미리정의(TestCase)
• 테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 && 수정사항) TC에 추가하고 설계를 개선

이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스는 간결

TOOLS

1. JUnit
   • Java 단위 테스트 프레임워크
2. XUit
   • 자바의 단

TDD 개발 장점

튼튼한 객체 지향적인 코드 생산

• 코드의 재사용 보장을 명시 || 소프트웨어 개발 => 철저한 모듈화
• 종속성, 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능 => 모듈을 추가하거나 제거해도 전체구조에 영향 X

재설계 시간의 단축

• 1. TC작성-> 개발자가 무엇을 해야하는지 정의 -> 개발시작
• 2. 테스트 시나리오를 작성 -> 예외사항에 대해 생각 -> 개발중 SW의 전박적인 설계가 변경되는 일을 방지

디버깅 시간의 단축

• 유닛 테스팅을 하는 이점.
• TDD의 경우 자동화된 유닛 테스팅을 전제 -> 버그를 쉽게 찾을 수 있다.

테스트 문서의 대체 가능

• 테스팅을 자동화와 동시에 테스트 근거를 산출

추가 구현의 용의

• 자동화된 유닛 테스팅을 전제, 테스트 기간을 획기적으로 단축