[CS] TDD :: 테스트 주도 개발

📌 TDD (Test Driven Development) :: 테스트 주도 개발
→ 반복 테스트를 이용한 소프트웨어 방법론
- 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현
- 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시함.

💡 eXtream Programming(XP)란? : 미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나 : 추가 요구사항이 생기더라도 실시간으로 반영할 수 있음

💡 단위 테스트(unit Test)란? : 말 그대로 한 단위(일반적으로 class)만을 테스트하는 것

 

💿 TDD의 개발주기

• RED 단계 : 실패하는 테스트 코드를 먼저 작성
• GREEN 단계 : 성공하기 위해 코드를 수정
• BLUE 단계 : 중복 코드를 제거하는 등의 리팩토링을 수행

 

💿 일반 개발 방식과 TDD 개발 방식의 비교

✅ 일반 개발 방식

: 요구사항 분석 → 설계 → 개발 → 테스트 → 배포 의 개발 주기

⇒ 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재

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

• 이러한 문제점이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문
• 보통 점진적으로 완벽한 설계로 나아가게 되는데, 이러한 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처리될 가능성이 큼
• 결론적으로 이러한 코드들은 재사용 및 관리가 어려워서 유지보수도 어려워짐

✅ TDD 방식

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

→ 이러한 단계가 반복적으로 진행되면서 코드의 버그는 줄어들고, 소스 코드가 간결해짐

→ 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감될 수 있음

 

💿 TDD의 장단점

✅ 장점

1. 높은 코드 안정성
   : 짧은 주기의 테스트 코드 개발 - 리팩토링 단계를 거치며 끊임 없이 보완하고 철저한 모듈화를 통해 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하여 코드의 안정성을 높일 수 있음
2. 재설계 시간의 단축
   : 설계 단계에서 테스트 시나리오를 작성하기 때문에 무엇을 해야하는지 정의하고 생각할 수 있어 완성도 높은 설계로 이어짐
   → 추후 설계가 변경되는 일을 방지할 수 있음
3. 디버깅 시간의 단축
   : 모듈별로 테스트를 자동화를 하지 않는다면 에러가 생겼을 경우 모든 레벨의 코드를 살펴봐야함.
   but, TDD의 경우 자동화된 단위테스트를 통해 특정 버그를 쉽게 찾을 수 있음
4. 테스트 문서의 대체 가능
   : 주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만듦. 이것은 단순 통합 테스트문서에 지나지 않으나 TDD를 하게될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있음
5. 추가 구현이 용이함
   : 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것.
   but, TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있음
   
   

✅ 단점 : 생산성 저하

• 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야하기 때문
• TDD 방식의 개발시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어남
• SI 프로젝트에서는 소프트웨어의 품질보다는 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않음