•
TDD란 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발방법론이다.
•
단순한 설계를 장려하고 자신감을 불어넣어주는 역할을 한다.
•
TDD는 크게 3가지 단계로 이루어진다
◦
빨강 - 요구사항 기반으로한 테스트를 작성한다. 컴파일조차 되지 않을 수 있지만 일단 작성한다.
◦
초록 - 작성한 테스트를 통과하게끔 구현한다. 테스트가 통과하기 위해 수단과 방법을 가리지 않아도 된다.
◦
파랑 - 앞서 작성한 코드를 리팩토링하는 과정이다. 매직 넘버나 리터럴을 상수화한다거나 중복을 메소드로 추출한다거나 도메인 객체의 필드를 검증하는 함수를 추가한다던지 부가적인 로직을 추가한다.
원칙
1.
실패하는 단위 테스트를 작성할 때까지 구현 코드(production code)를 작성하지 않는다.
2.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
장점
1.
TDD는 초반 생산성이 느릴 수 있지만, 이후 유지보수 단계까지 고려했을 때는 높은 생산성을 가질 수 있다.
2.
기능에 대한 테스트 코드가 항상 존재하기 때문에, 기능 수정시에도 확신을 가지고 수정할 수 있다.
3.
지금까지 아무 이유없이 코드를 추가했다면, TDD에서는 근거를 가지고 코드를 추가할 수 있다.
4.
위와 같은 TDD의 장점은 곧 개발자에게 자신감을 불어넣어 준다. 기능이 변경되었을 때 프로그램이 오동작하지는 않을지 걱정했다면 이제는 먼저 작성해놓은 테스트 코드를 믿고 과감하게 실행에 옮길 수 있을 것이다.
단점
•
마감기한이 촉박한 경우, 단기적인 생산성이 낮은 TDD는 적합하지 않은 선택이 될 수 있다.
•
TDD도 결국 하나의 개발 방법론이자 도구이기 때문에, 현 상황이 TDD를 적용하기 알맞은 상황인지를 명백히 고려할 필요가 있다
