TDD
TDD?
요즘 개발자 관련글들에서 TDD라는 용어가 많이보인다. ( 21/3월 기준 )
그렇다면 TDD가 뭔지 알아보도록하자:)
*테스트 주도 개발(Test-driven Development, TDD)*은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스중 하나이다.
- 우선 개발자는 바라는 향상 또는 새로운 함수를 정의하는 (초기적 결함을 점검하는 자동화된 테스트 케이스를 작성한다.
- 그런후에, 그 케이스를 통과하기위한 최소한의 양의 코드를 생성한다.
- 그리고 마지막으로 그 새코드를 표준에 맞도록 리팩토링한다.
이 기법을 개발했거나 ‘재발견’ 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 말하였다.
TDD에 대해 좀더 쉽게 접근해본다면 “테스트 주도 개발(Text-Driven Development)”이라는 용어 그대로 개발을 하는데 있어 테스트가 주가 되어 개발한다는 의미가 되겠다.
→ 즉, “테스트를 염두에둔 프로그램 개발방법” 정도가 되겠다.
아래의 그림을 통해 쉽게 이해해보자
이와같이 기존 개발 프로세스와 차이점을 알수있다.
테스트 코드를 작성하며 결과를 예상해볼수있기에 설계의 문제로 인한 오류 개선속도가 한층 빨라질것을 직관적으로 알수있다.
그렇다고 무작정 TDD를 사용하기에는 명확한 이유가 될수는 없기에 TDD의 장점에 대해알아보자
TDD의 장점
객체지향적 코드개발
- 테스트 코드를 먼저 작성한다면 좀 더 명확한 기능과 구조를 설계할수 있다.
- 각각의 함수 정의시 각각의 기능들에 대해 철저히 구조화 시켜 코드를 작성할수 있다.
- 테스트의 용이성을 위해 복잡한 기능을 한 함수에 모두 구현하지 않고 모든코드의 재사용성을 보장하며 코드를 작성함으로 기본적으로 객체지향적 코드가 된다.
설계수정 시간의 단축
- 테스트 코드를 먼저작성하기에 최초 설계안을 만족시키며 입출력 구조와 기능의 정의를 명확히 하여 설계의 구조적 문제를 쉽게 찾을수 있다.
- 테스트 시나리오를 작성해봄으로 코드 개발전 기능을 구현하기위한 예외 상황을 미리 확인하고 조사하게되어 예외 코드를 작성하기 쉬워진다.
디버깅 시간의 단축
- 단위 테스트 기반의 테스트 코드를 작성하므로 추후 문제발생시 모듈별로 테스트를 진행해 문제지점을 쉽게 찾을수있다.
예를 들어 문제가 발생할 수 있는 지점은 DB영역, Application 영역, Data영역, Memory 영역등 모든 영역을 통합 테스트시 문제 지점을 쉽게 찾을수 없지만, 각각의 단위 테스트 진행시 영역을 분할하여 쉽게 찾아낼수 있게된다.
유지보수의 용이성
- 대부분의 개발자는 설계 및 코드 작성시 기술적인 관점을 바라보며 기능자체의 구현에 초점이 맞춰짐으로 코드가 복잡해지고 테스트가 어려워지지만,
- TDD 개발로 인해 항상 그 테스트 요소들이 사용자 관점으로 정의되고 진행되기에 입력과 출력의 흐름이 명확해지고 추후 구조의 변경 및 소스 수정시 구조를 쉽게 파악하고 빠른 수정이 가능해진다.
- 더불어 재사용테스트도 쉽게 가능해진다.
테스트 문서의 대체가능
- 대부분의 개발 프로젝트 진행시 테스트를 진행하게되면 단순 통합 테스트에 지나지 않는다. 즉, 내부적 모듈이 어떻게 테스트 되었는지 제공할수 없다.
- 하지만 TDD를 구현하게되면 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할수있게된다.
TDD를 사용하며 개별 테스트를 일일히 진행하며 완성시키다보니 개발 시간이 늦어지는 단점이 보일수 있겠지만, 전체적인 개발시간은 비슷하거나 단축되는 효과가 있게된다. 이후 코드 수정 및 구조추가의 용의성을 생각했을때 TDD를 적용한 개발방법이 많은 도움이 될수있다.
