실패하는 테스트 코드를 먼저 작성한다.
실제 코드가 반영되지 않았기에 실패해야 한다.
실패하는 것이 확인 되어야, 테스트가 검증력을 가진다고 신뢰할 수 있다.
테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
테스트 성공을 위한 최소한의 코드 그 이상을 변경하거나 추가하면 안 된다.
리팩토링 과정에서 작성된 코드를 개선한다.
중복코드를 제거하고 가독성을 높이며 성능을 고려한다.
TDD는 코드의 재사용을 목표로 하기 때문에 TDD를 통한 소프트웨어 개발을 할 때 기능별로 모듈화가 이루어진다. 즉 모듈이 의존성과 종속성이 낮게 조합된다. 따라서 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.
기본적으로 TDD는 단위 테스트 기반(일반적으로 class)의 테스트 코드를 작성한다. 따라서 추후 문제가 발생하였을 때 각각의 모듈별로 테스트를 진행할 수 있으므로 문제의 지점을 쉽게 찾을 수 있다.
TDD는 테스트코드를 먼저 작성하기 때문에 최초 설계안을 만족하게 한다. 또한 진행하면서 입출력 구조와 기능의 정의를 명확하게 하고, 테스트 시나리오를 작성하며 다양한 예외사항에 대해 생각해볼 수 있으므로 설계의 구조적 문제를 바로 찾아내어 수정시간을 단축한다.
다른 개발 프로젝트의 테스트는 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다.
반면, TDD를 사용하면, 테스트 코드를 작성하는 과정에서 히스토리가 남는다. TDD를 하게 될 때 테스팅을 자동화시킴과 동시에 더욱 정확한 테스트 근거를 산출해 정의서를 작성할 수 있다. 따라서 TDD를 통해 작성한 테스트 코드를 트래킹하면서 과거에 어떤 인과관계로 의사결정을 했는지 확인하기 쉽다.
TDD 그림
: http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/
TDD 설명
1)http://www.incodom.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C
2) http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/
3) https://media.fastcampus.co.kr/knowledge/dev/tdd/