2. TDD and Traditional Testing

TDD는 기본적으로 단위 테스트를 통해 자신의 소스 코드를 확인하는 효과를 가지고 있는 프로그래밍 기술이다. However, there is more to testing than this. 기능 테스트, 인수 테스트, 시스템 통합 테스트와 같은 전통적인 테스트 역시 고려할 필요가 있다. 이 들 테스트 중 대다수는 여러분이 하기로 선택했다면(또는 해야만 한다면) 프로젝트 초기에 끝낼 수 있을 것이다. 사실 XP에서 코드가 작성되기 전 또는 작성 되면서 프로젝트의 주요관계자들에 의해 사용자를 위한 인수 테스트는 명세된다. 이렇게 함으로써 프로젝트의 주요관계자들에게 시스템이 사용자의 요구사항을 만족시킬 것이라는 자신감을 주게된다.

전통적인 테스트에서 성동적인 테스트는 하나 또는 그 이상의 결점을 찾아낸다. TDD에서도 똑같다. 테스트가 실패하게 되면 문제를 해결할 필요가 있다는 것을 알았기 때문에 일을 진행하면 된다. 이보다 더 중요한 것은 테스트에 실패가 없을 때는 분명한 성공의 척도가 된다는 것이다. TDD는 개발하고 있는 시스템이 요구사항을 만족시키고 있다는 자신감을 증진시켜준다. 따라서 자신감을 가지고 일을 진행할 수 있다.

전통적인 테스트와 마찬가지로, 시스템의 위험 요소들이 많을 수록 많은 테스트가 요구된다. With both traditional testing and TDD you aren'tstriving for perfection, instead you are testing to the importance of thesystem. AgileModeling (AM)을 달리 말하자면, "목적을 가진 테스트"를 해야하고 왜 그것을 테스트 하고 있는지 그리고 어디까지 테스트 되어야 하는지를 알아야 한다. TDD의 흥미로운 부가적인 효과로 전통적인 테스트가 보장하지 못했던 100% 모든 코드에 대한 테스트를 할 수 있다는 것이다. 일반적으로 전통적인 테스트 기술보다 TDD의 결과물이 명백히 낫다고 말할 수 있다.

If it's worth building, it's worth testing.

If it's not worth testing, why are you wasting your time working on it?