[Spring] TDD(Test-Driven-Development)

TDD(Test-Driven-Development)란?

 

TDD란 '테스트 주도 개발' 이라고 불립니다. 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현합니다. 짧은 개발 주기의 반복에 의존하는 개발 프로세스입니다. 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시합니다. 

 

eXtream Programming(XP)란?

 

미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나입니다. 이 방법론은 추가 요구사항이 생기더라도 실시간으로 반영할 수 있습니다.

 

TDD 개발주기

 

맨 위의 그림(TDD의 개발주기)를 참고하시면 됩니다.

 

- Red단계 : 실패하는 테스트 코드를 먼저 작성합니다.

- Green단계 : 테스트 코드를 성공시키기 위한 실제 코드를 작성합니다.

- Yellow단계 : 중복 코드 제거, 일발화 등의 리팩토링을 수행합니다.

 

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

 

TDD 개발 방식의 장점

 

• 보다 튼튼한 객체 지향적인 코드 생산

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

• 재설계 시간의 단축

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

• 디버깅 시간의 단축

TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있습니다.

• 테스트 문서의 대체 가능

TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있습니다.

• 추가 구현의 용이함

TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있습니다.

 

TDD 개발 방식의 단점

 

가장 큰 단점은 바로 생산성 저하입니다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간 테스트를 하면서 고쳐나가야 하기 때문입니다. TDD방식의 개발 시간은 일반적인 개발 방식에 비해 대략10~30% 정도가 늘어납니다.