TDD(Test Driven Development)?
- 반복 테스트를 이용한 S/W 방법론
- 짧은 주기의 반복에 의존하는 개발 프로세스
- 애자론 방법론(eXtream Programming)의 'Test-First'개념에 기반을 둔 단순한 설계를 중심
Extream Programming(XP)
- 미래에 의한 예측을 최대한 하지않고 지속적으로 프로토타입을 완성
- 추가 요구사항 => 실시간 반영
단위 테스트(unit Test)
TDD 개발주기
- {Red}
- {Green}
- 테스트 코드를 성공시키기 위한 실제 코드를 작성
- {Blue}
- 중복 코드 제거, 일반화 등의 리펙토링을 수행
실패하는 테스트 코드를 작성할 때까지 실제코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성
=> 실제 코드에 대해 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할수 있고, 정확한 요구사항에 집중
일반 개발 방식과 TDD 개발방식의 비교
일반 개발 방식
일반적인 개발방식
'요구사항분석 -> 설계 -> 개발 -> 테스트 -> 배포'
단점 : 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재
- 소비자의 요구사항이 처음부터 명확하지 X
- 처음부터 완벽한 설계는 어려움
- 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하
- 자체 테스트 비용이 증가
재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처 될 가능성이 크다.
결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워서 유지보수를 어렵게 만든다.
TDD 개발방식
일반적인 개발방식의 차이점
- 테스트 코드를 작성한 뒤에 실제 코드를 작성
- 디자인(설계)단계에서 프로그래밍 목적을 반드시 미리 정의
- 테스트 해야 할지 미리정의(TestCase)
- 테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 && 수정사항) TC에 추가하고 설계를 개선
이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스는 간결
- JUnit
- XUit
TDD 개발 장점
튼튼한 객체 지향적인 코드 생산
- 코드의 재사용 보장을 명시 || 소프트웨어 개발 => 철저한 모듈화
- 종속성, 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능 => 모듈을 추가하거나 제거해도 전체구조에 영향 X
재설계 시간의 단축
- TC작성-> 개발자가 무엇을 해야하는지 정의 -> 개발시작
- 테스트 시나리오를 작성 -> 예외사항에 대해 생각 -> 개발중 SW의 전박적인 설계가 변경되는 일을 방지
디버깅 시간의 단축
- 유닛 테스팅을 하는 이점.
- TDD의 경우 자동화된 유닛 테스팅을 전제 -> 버그를 쉽게 찾을 수 있다.
테스트 문서의 대체 가능
추가 구현의 용의
- 자동화된 유닛 테스팅을 전제, 테스트 기간을 획기적으로 단축