소프트웨어 개발 방법론 중 하나인 TDD(test-driven-development)에 대한 궁금증과 사용을 위한 근거를 찾아 보려한다.
TDD(test-driven-development)란?
TDD는 소프트웨어가 완전히 개발되기 전
요구 사항을 테스트 사례로 변환 하고 모든 테스트 사례에 대해 소프트웨어를 반복적으로 테스트하여 모든 소프트웨어 개발을
추적하는 소프트웨어 개발 프로세스이다.
즉, 테스트 -> 코드 작성 -> 리팩토링 방식
TDD 방식
-
실패한 테스트 케이스를 작성
: 의도된 실패를 통해서 원하는 기능을 명확히 하는 단계 -
코드 작성
: 테스트를 통과하는 데 필요한 최소한의 코드만 작성하는 단계 -
리팩토링
: 코드 정리 및 테스트의 추가 사용 사례를 정리하는 단계이후 테스트가 여전히 통과하는지 재확인하고
위 과정을 반복한다.
TDD를 왜 사용하는가?
그렇다면 여기서 왜 먼저 실패한 테스트 케이스를 작성하고,
나아가 왜 TDD를 적용하는 이유는 무엇일까?
테스트 주도 개발의 첫 단계로
먼저 실패 테스트 케이스를 작성한다.
이를 통해 아래와 같은 장점을 갖는다.
-
무엇을 달성해야 하는지 명확하게 볼 수 있다.
(새로운 테스트는 달성하려는 기능 구현을 포함해야하며, 이 단계 이후 다음 단계로 진행) -
안전한 단계로 코딩할 수 있다.
(코딩 시 버그와 그 원인의 감지)
- 반복 없이 코드를 생성할 수 있습니다
(각 코드 단위 앞에 해당 기능을 설명하는 테스트가 있기 때문에 불필요한 코드 작성을 피할 수 있다)
장점
- 프로세스 초기의 결함 제거를 통해
결험으로 인한 고질적인 문제 예방과 비용 절감의 효과 - 모듈화되고 유연하며 확장 가능한 코드로 이어질 수 있다
- 개발자로 하여금 클라이언트의 요구사항을 명확히 하는데 도움을 준다.
- 코드에 대한 신뢰성 증가
(모든 기능은 하나 이상의 테스트를 거친다)
단점
- 초기 개발 단계의 시간이 많이 걸린다.
- 단발성 개발프로젝트에는 부적절하다.
정리
테스트 주도 개발 방식은 하나의 방법론으로써 반드시 적용되어야하는 것은 아니다.
하지만 코드 품질에 대한 높은 신뢰성을 부여하고, 새로운 기능의 지속적인 추가 및 프로젝트의 확장에 많은 이점을 가지고 있다.
이러한 이유로 더욱 알아보고 프로젝트에 적용시켜보려 한다.
