TDD

TDD란?

• 테스트 주도 개발(TDD, Test Driven Development)은 소프트웨어를 개발하는 여러 방법론 중 하나
• 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현

TDD의 개발 주기

• Red 단계에서는 실패하는 테스트 코드를 먼저 작성
  • 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가
  • 추가된 테스트가 실패하는지 확인
  • 실패하는 것이 확인 되어야, 테스트가 검증력을 가진다고 신뢰할 수 있음
    • 실패의 이유는 운영 코드가 아직 변경되지 않았기 때문이어야 하며 테스트 코드의 문제이면 안됨

• Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성
  • 추가된 테스트를 포함하여, 모든 테스트가 성공하게끔 운영 코드를 변경
  • 테스트의 성공은 모든 요구사항을 만족했음을 의미
  • 테스트 성공을 위한 최소한의 코드 변경만 진행
  • TDD를 반복하다 보면, 지루함을 느끼는 프로그래머가 많지만 TDD에서는 테스트 성공을 위한 최소한의 코드 그 이상을 변경하거나 추가하면 안됨
    • 테스트 되지 않은 코드가 중간에 추가되면, 이후 리팩토링 등의 다른 프로세스에서 어떤 부작용을 가져올지 알 수 없기 때문

• Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행
  • 코드베이스를 정리
  • 인터페이스 뒤에 숨어 있는 구현 설계를 개선
  • 가독성, 적용성, 성능을 고려

Tip! TDD 세부 프로세스
‘단위 테스트 작성 → 단위 테스트 실행 → 운영 코드 작성 → 단위 테스트 실행 → 설계 개선(리팩토링) → 단위 테스트 → … ‘ 실행 반복한다.

• 중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것
• 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있음

TDD의 개발 방식

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

• 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고, 소스코드는 간결해짐
• 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감