- Test Driven Development
- 테스트 주도 개발: 테스트가 개발을 이끌어 나간다.
Test the program before you write it!-Kent Beck
개발을 할 때 보통 설계(디자인)을 한 후 코드 개발과 테스트 과정을 거치게 되는데 TDD는 기존 방법과는 달리 테스트 케이스를 먼저 작성한 후에 실제 코드를 개발하는 리팩토링 절차를 밟는다.
애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시한다.
TDD 개발 주기
위 그림은 TDD의 개발 주기를 표현한 것이다.
- { Red } 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
- { Green } 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
- { Blue } 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
테스트 코드를 작성할 때 까지 실제 코드는 작성하지 않는다. 이로 인해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의하여 불필요한 설계(오버 엔지니어링)을 피할 수 있고, 요구 사항에 맞게 개발 할 수 있다.
반복 적인 테스트와 수정을 통해 고품질의 소프트웨어를 탄생시킬 수 있다.
기존의 개발 방식
기존의 개발 방식은 ‘요구 사항 분석 
설계 개발 테스트 배포’ 형태의 개발 주기를 갖는다.
이러한 방식은 치명적인 단점을 가지고 있다.
- 소비자의 요구 사항이나 설계 미흡 시 재 설계, 코드 수정의 과정에서 불필요한 코드가 남거나 중복될 가능성이 크다.
- 작은 부분을 테스트 하더라도 전체를 테스트해야 하므로 전체적인 버그를 검출하기 어려워진다.
- 그 결과 어디서 버그가 발생할 지 모르기 때문에 잘못된 코드라도 수정하지 않으려고 하는 현상이 생길 수 있다.
- 이런 현상은 소스 코드의 품질 저하와 직결되며, 결론적으로 이런 코드들은 재 사용이 어렵고 관리가 힘들어 유지 보수를 어렵게 만든다.
TDD 개발 방식
TDD와 기존 개발 방식의 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것이다.
설계 단계에서 프로그래밍 목적을 반드시 정의해야만 하고, 무엇보다 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다
테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정 사항)은 테스트 케이스에 추가하고 설계를 개선한다.
이후 테스트에 통과된 코드만을 개발 단계에서 실제 코드로 작성한다.
이러한 단계가 반복되면서 자연스럽게 코드의 버그가 줄어들고 소스 코드가 간결해진다.
TDD 장점
- 작업과 동시에 테스트를 진행하면서 실시간으로 오류 파악이 가능하다 (시스템 결함 방지)
- 짧은 개발 주기를 통해 고객의 요구 사항을 빠르게 수용 가능하다(추가 구현의 용이성)
- 피드백이 가능하고 진행 상황 파악이 쉽다
- 자동화 도구를 이용한 TDD 테스트 케이스를 단위 테스트로 사용이 가능하다
Java는 JUnit, C와 C++은 CppUnit 등
- 개발자기 기대하는 앱의 동작에 관한 문서를 테스트가 제공해 준다
- 또한 이 테스트 케이스는 코드와 함께 업데이트 되므로 문서 작성과 거리가 먼 개발자에게 매우 좋다
- 자연스럽게 테스트 커버리지가 높아진다
- 오버 엔지니어링을 방지할 수 있다(불필요한 내용을 줄일 수 있음)
이러한 TDD의 장점에도 불구하고 모두가 이 개발 프로세스를 따르지는 않는다. 그 이유는
TDD 단점
기존 개발 프로세스에 테스트 케이스 설계가 추가되므로 생산 비용이 증가한다.
테스트의 방향성, 프로젝트의 성격에 따른 테스트 프레임워크 선택 등 추가로 고려할 부분이 증가한다.
참고