TDD?

TDD

 - TDD란 Test Driven Development의 약자로 '테스트 주도 개발' 이라고 한다.

 

 - 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를

   추가하는 단계를 반복해서 구현한다.

 

 - 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtreem Programming( XP )의

   Test-First 개념에 기반을 둔 단순한 설계를 중요시한다.

 

※ eXtream Programming ( XP )란?

 - 미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기반 방법 중 하나

 - 이 방법론은 추가 요구사항이 생기더라도 실시간으로 반영할 수 있다.

 

단위 테스트 ( Unit Test ) 란?

 - 한 단위 ( 일반적으로 Class ) 만을 테스트 하는 것이다.

 

※  TDD 개발 주기

 

 

{ RED } 단계에서는 실패하는 테스트 코드를 먼저 작성한다.

{ Green } 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.

{ Blue } 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

 

 - 중요한 것은 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소

   실제 코드를 작성하는 것이다.

 - 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구

   사항에 집중할 수 있다.

 

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

 - 일반 개발 방식은 ' 요구사항 분석 => 설계 => 개발 => 테스트 => 배포 ' 형태의 개발 주기를 갖는다

 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.
 
 1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
 2. 처음부터 완벽한 설계는 없다.
 3. 자체 버그 검출 능력 저하 또는 소스 코드의 품질이 저하 될 수 있다.
 4. 자체 테스트 비용이 증가할 수 있다.

 - 이런 문제점이 발생하는 이유는 어떤 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문이다.

 => 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해 재설계하게 된다.

   => 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복될 가능성이 크다.

       => 코드의 재사용이 어렵고 관리가 어려워 유지 보수를 어렵게 만든다.

 

 - 작은 부분의 수정에도 모든 부분을 테스트 해야 하므로 전체적인 버그를 검출하기 어려워져 자체 버그 검출 능력이

   저하된다.

 - 소스 코드의 품질 저하와 직결되고 작은 수정에도 모든 기능을 다시 테스트해야 해 테스트 비용이 증가하게 된다!!

 

TDD 개발 방식

 - TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤 실제 코드를 작성하는 것이다.

 - 디자인 ( 설계 ) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만하고, 무엇부터 테스트해야 할지

   미리 정의 (테스트 케이스 작성 ) 해야만 한다.

 

 - 이 후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.

 - 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.

TDD 개발 방식의 장점

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

 - TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능별 철저한 모듈화가 이뤄진다.

 - 이는 종속성과 의존성이 낮은 모듈로 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도

   소프트웨어 전체 구조에 영향을 미치지 않는다.

 

2. 재설계 시간 단축

 - 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다.

   또한 테스트 시나리오를 작성하면서 다양한 예외 사항에 대해 생각할 수 있다. 

 

3. 디버깅 시간 단축

 - 이는 유닛 테스팅의 이점으로 사용자의 데이터가 잘못 나온다면 DB 문제인지, 비즈니스 레이어의 문제인지 UI의 문제

   인지 실제 모든 레이어들을 전부 디버깅 해야하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 특정 버그를 쉽게 

   찾아낼 수 있다.

 

4. 테스트 문서의 대체 가능

 

5. 추가 수현의 용이함.

 - 개발에 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을

   미칠지 알지 못한다는 것이다.하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 

   단축 할 수 있다.

 

TDD 개발의 단점

1. 생산성 저하.

 - 개발 속도가 느려진다 생각하는 사람이 많아 TDD에 대해 반신반의 한다.

2. 자신의 개발 방식을 많이 바꿔야한다.

3. TDD는 이렇게 해야된다는 이미지 ( 틀 ) 이 있다.

 - 반드시 툴 ( 단위 테스트 프레임워크 ) 를 써서 개발해야 된다. 라고 생각한다.

 - 이러한 규칙에 얽매이는 것은 애자일 방식이 아니다.

 - 결국 규칙에 얽매여 똑같은 테스트를 copy  & paste 하게 된다.

 - 도구 / 규칙에 집착하다 보니 TDD가 어려워진다.

---

 

TDD란? 테스트 주도 개발 - 하나몬