TDD 라는것은 무엇인가?

TDD란?

• TDD는 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다. 반복 테스트를 통한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
  

• 빨간색 단계에서는 실패하는 코드를 먼저 작성한다.

• 초록색 단계에서는 테스트코드를 통과하기 위한 실제 코드를 작성한다.

• 파란색 단계에서는 중복되는 코드는 제거하고 코드 리팩토링을 진행한다.

일반적인 개발 방식과의 다른점?

설치 -> 개발 -> 테스트

이러한 방식의 단점

• 소비자의 요구사항이 처음부터 명확하지 않을 수 있다. -> 변경사항이 많을 수 있다.

• 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.

• 자체 테스트 비용이 증가할 수 있다. -> 개발 후 테스트여서 테스트 비용이 증가할 수 있다.

TDD개발방식

• TDD는 테스트 코드를 작성한 뒤에 실제 코드를 작성한다.
  디자인(설계) 단계에서 프로그래밍 목적을 미리 정의해야하고, 또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다.
  테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들은 테스트 케이스에 추가하고 설계를 개선한다. 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.

이러한 방식이 반복 될수록 자연스럽게 코드의 버그가 감소하고 소스코드가 간결해지게 된다.

TDD개발방식의 장점

• 보다 튼튼한 객체 지향적인 코드 생산
  TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.

• 재설계 시간의 단축
  테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

• 디버깅 시간의 단축
  이는 유닛 테스팅을 하는 이점이기도 하다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모ㄱ든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다.

• 추가 구현의 용이함
  개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

그렇다면 TDD는 어떤 상황에서 해야할까?

만약 어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 뻔하다면 TDD를 하지 않아도 된다. 또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 된다.

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