TDD

고장난 고양이·2022년 7월 25일

개발지식

목록 보기

19/25

TDD(Test Driven Development)란?

테스트 주도 개발

기조의 개발 프로세스[그림1]과 다음과 같은 차이가 있다. 이런이유로 test first development라고도 한다.

[TDD의 사용 이유]

TDD는 작가가 책을 쓰는 과정과 유사하다. 책을 쓸 때는 목차를 처음 구성한다. 이후 각 목차에 맞는 내용을 구상하여 초안을 작성하고 고쳐쓰기를 반복한다. 이 과정을 TDD에 비유하면 목차구성은 “테스트코드 작성”, 초안작성은 “코드개발”, 고쳐쓰기는 “코드수정”에 해당한다. 반복적인 검토와 고쳐쓰기를 통해서 좋은 글이 완성되는 것처럼 소프트웨어도 반복적인 테스트와 수정을 통해서 고품질의 소프트웨어를 만들 수 있다.

애자일 방법론과 같이 불확실성 및 변동성이 높을 시에는 "피드백"과 "협력"이 중요하다. 상대적으로 잦은 패드백과 협력이 이루어지기에 좋은 결과를 만들어 낼수가 있다.
깔끔한 코드를 작성할 수 있다.
- 처음 작성할 때에는 귀찮고 개발을 느리게 한다는 느낌을 받을 수 있지만, 장기적으로 보면 반드시 개발 비용을 아껴줄 것이다.
장기적으로 개발 비용을 절감할 수 있다.
개발이 끝나면 테스트 코드를 작성하는 것은 매우 귀찮다. 실패 케이스면 더욱 그렇다.

[ TDD 방법 및 순서 ]

실패하는 작은 단위 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다.
빨리 테스트를 통과하기 위해 프로덕션 코드를 작성한다. 이를 위해 정답이 아닌 가짜 구현 등을 작성할 수도 있다.
그 다음의 테스트 코드를 작성한다. 실패 테스트가 없을 경우에만 성공 테스트를 작성한다.
새로운 테스트를 통과하기 위해 프로덕션 코드를 추가 또는 수정한다.
1~4단계를 반복하여 실패/성공의 모든 테스트 케이스를 작성한다.
개발된 코드들에 대해 모든 중복을 제거하며 리팩토링한다.

[TDD는 언제 써야할까?]

만약 어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 뻔하다면 TDD를 하지 않아도 된다.
또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 된다. 그렇다면 TDD는 어떤 상황에서 해야할까?

처음해보는 프로그램 주제
-나에 대한 불확실성이 높은 경우
고객의 요구조건이 바뀔 수 있는 프로젝트
- 외부적인 불확실성이 높은 경우
개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
- 외부적인 불확실성이 즉, 불확실성이 높을 때 TDD를 하면 된다.
- TDD의 효과

모든 애자일의 실천법은 피드백과 협력을 동시에 증진시킨다.

TDD의 장단점

장점	단점
튼튼한 객체 지향적인 코드 생산 가능	생산성의 저하
재설계 시간의 단축
디버깅 시간의 단축
테스트 문서의 대체 가능
추가 구현의 용이함

(장점)

TDD는 코드의 재사용 보장을 명시한다. 즉 TDD를 통해 코드의 모듈화가 이루어지며 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게하여 객체지향적인 코드생산이 가능해진다.
테스트 코드를 먼저 작성하기에 분명히 정의하고 개발을 시작할 수 있기에 설계 변경이 되는 경우를 줄일수 있다. 또, 여러 예외상황을 미리 생각하기에 설계변경 방지 역시 가능하다.
자동화 된 유닛테스팅을 전제하므로 특정 버그를 손 쉽게 찾아낼 수 있다.
주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

(단점)