TTD?
TDD란 Test Driven Development의 약자로 테스트 주도 개발이라는 의미이다.
TDD는 설계 이후 코드 개발 및 테스트케이스를 작성하는 기본의 개발 프로세스와 다르게 테스트케이스를 작성 한 후 실제 코드를 개발하여 리펙토링하는 절차를 따른다.
이러한 이유로 TDD를 Test First Development라고도 한다.
반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현하다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 XP의 Test-First 개념에 기반을 둔 단순한 설계를 중요시한다.
XP(eXtream Programming)?
- 미래에 대한 예측을 최대한 하지 않고, 지속적으로 프로토타입을 완성하는 애자일 방법론 중 하나이다. 이 방법론은 추가 요구사항이 생기더라도, 실시간으로 반영할 수 있다.
TDD 개발주기
TDD 개발주기는 세 단계를 거쳐 만들어진다.
Red 단계에서는 실패하는 코드를 작성한다.
Green 단계에서는 테드스 코드를 성공시키기 위한 실제 코드를 작성한다.
Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
여기서 중요한 것은 실패하는 테스트 코드를 작성할 때가지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다.
위와 같이 코드를 만들게 되면 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.
일반적인 개발과 TDD개발의 차이점
일반적인 개발
보통 개발 방식은 1. 요구사항 분석, 2. 설계, 3. 개발, 4. 테스트, 5. 배포의 형태의 개발 주기를 갖는데 이러한 방식은 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.
그 이유로는 아래와 같은 문제점들이 존재한다.
- 소비자의 요구사항이 처음부터 명확하지 않을 수 있기에, 처음부터 완벽한 설계는 어렵다.
- 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
- 자체 테스트 비용이 증가한다.
위와 같은 문제점들이 발생하는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문이다.
보통 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해, 재설계되며 점진적으로 완벽한 설계로 나아간다.
하지만 재설계로 인해 코드를 삽입, 수정, 삭제 하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 크다.
TTD 개발
TTD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.
설계 단계에서 프로그래밍 목적을 미리 정의해야만 하고, 무엇을 테스트해야 할지 미리 정의 해야만 한다.
- 테스트 코드를 작성하는 도중에 발생하는 예외 사항 들은 테스트 케이스에 추가하고 설계한다.
- 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.
이러한 반복적인 단계가 진행되면서 자엽스럽게 버그가 줄어들고, 소스코드는 간결해진다.
또한, 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.
TDD의 장단점
장점
- 디버깅 시간을 단축할 수 있다.
- 코드가 내 손을 벗어나기전에 가장 빠르게 피드백 받을 수 있다.
- 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다.
- 재설계 시간을 단축 할 수 있다.
- 추가 구현이 용이하다.
- 개발이 완료된 소프트웨어에 어떤 기능을 추가 할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 모른다는 것인데 이를 바로 확인 할 수 있기 때문에 추가 로직을 구현하는데 용이하다.
단점
- 가장 큰 단점은 생산성의 저하이다.
- 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다.
- 이제까지 자신이 개발하던 방식을 많이 바꿔야 한다.
- 구조에 얽매힌다.
- 프로젝트를 진행하면서 어려운 예외가 생길 수 있는데 그것 때문에 고민하는 순간이 찾아오게 된다.
