[CS] TDD(Test-Driven-Development)

---

알고있으면 좋은 Computer Science Tip✨

---

TDD란 무엇인가?

• TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
• 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며 애자일 방법론 중 하나인 eXtream Programming(XP)의 'Test-First' 개념에 기반을 둔 단순한 설계를 중요시한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 말하였다.

 

(1) TDD 개발주기

• Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
• Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
• Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
• 중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

 

(2) 일반 개발 방식과 TDD 개발 방식 비교

 

• 일반 개발 방식
  1.  '요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포'의 형태의 개발 주기를 갖는데 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.
     1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있고, 처음부터 완벽한 설계는 어렵다.
     2. 자체 버그 검출 능력이 저하 되거나 소스코드의 품질이 저하 될 수 있다.
     3. 자체 테스트 비용이 증가할 수 있다.

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

 

(3) TDD 장·단점

• 장점
  1. [높은 코드 안정성] - 짧은 주기의 테스트 코드 개발-리팩토링 단계를 거치며 끊임 없이 보완하고 철저한 모듈화를 통해 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하여 코드의 안정성을 높일 수 있다.
  2. [재설계 시간의 단축] - TDD는 설계 단계에서 테스트 시나리오를 작성하기 때문에 무엇을 해야하는 지 정의하고 생각할 수 있어 완성도 높은 설계로 이어지며, 추후 설계가 변경되는 일을 방지할 수 있다.
  3. [디버깅 시간의 단축] - 모듈 별로 테스트를 자동화를 하지 않는 다면 에러가 생겼을 경우 모든 레벨의 코드를 살펴봐야한다. 하지만 TDD의 경우 자동화된 단위테스트를 통해 특정 버그를 쉽게 찾을 수 있다.
• 단점
  1. 생산성의 저하가 가장 큰 단점이다. 한 번 개발할 코드를 2번 이상 반복하게 되어 일반적인 개발 방식보다 개발 시간이 늘어날 수 밖에 없다.
  2. 또 단순 개발이나 단발성 프로젝트의 경우 개발기간이 짧아 TDD를 적용하게 되었을 때 Ctrl + C, Ctrl + V를 통한 뻔하고 중복된 테스트 코드를 작성했을 때는 비효율적일 수 있다.