TDD(Test Driven Development)

반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복 및 구현한다.

 

  Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다. 
  Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다. 
  Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

 

 

[일반적]

보통의 개발 방식은 '요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포'의 형태의 개발 주기를 갖는데 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.

 

왜냐하면, 

1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
2. 따라서 처음부터 완벽한 설계는 어렵다. 
3. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
4. 자체 테스트 비용이 증가할 수 있다.

보통 고객의 요구사항 또는 디자인의 오류 등에 의해 재설계하여 점진적으로 완벽한 설계가 된다. 하지만, 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다.

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

 

 

[TDD]

TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고,

또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다. 

1. 테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들은 테스트 케이스에 추가하고 설계를 개선한다.
2. 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.

효과

1. 디버깅 시간을 단축 할 수 있다.

2. 코드가 내 손을 벗어나기 전에 가장 빠르게 피드백 받을 수 있다.

3. 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다.

4. 재설계 시간을 단축 할 수 있다.

5. 추가 구현이 용이하다.

 

단점

1. 가장 큰 단점은 바로 생산성의 저하이다. 

2. 이제까지 자신이 개발하던 방식을 많이 바꿔야 한다. 

3. 구조에 얽매힌다.

 

 

 

 

TDD는 어떤 상황에서 해야할까?

• 처음해보는 프로그램 주제
• 나에 대한 불확실성이 높은 경우
• 고객의 요구조건이 바뀔 수 있는 프로젝트
• 외부적인 불확실성이 높은 경우
• 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
• 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
• 불확실성이 높을 때 TDD를 하면 된다.