TDD란

1. TDD란 무엇인가

- 먼저 TDD는 1999년도 XP(Extreme Programing)라는 애자일 기반의 개발 방법론이 자리 잡을 때 처음 소개가 되었다. 이 그룹에서는 프로그래밍 전에 테스트 코드를 먼저 작성하면 어떨까라고 생각하고 시도를 해봤는데 이때 테스트 이후에 작성되는 코드의 퀄리티가 꽤 인상적이었기 때문에 TDD가 애자일 방법론에 도입되기 시작했다.

- 즉 개발을 하기 전에 테스트 코드를 먼저 작성한다는 것이다.

1) 일반적인 개발 프로세스

2) TDD를 도입한 개발 프로세스

- 테스트 코드를 작성한 뒤에 코드를 작성한다.

- 정확한 프로그래밍 목적을 디자인 단계에서 반드시 미리 정의해야만 하고 또 무엇을 테스트해야 할지 미리 정의해야만 한다.

2. TDD의 장점

- 높은 퀄리티의 소프트웨어를 보장한다는 것

1) 보다 튼튼한 객체지향적인 코드 생산 가능

- TDD는 모든 코드가 재사용성 기반으로 작성되어야 하기 때문에 보다 튼튼한 코드 생산이 이뤄지게 된다.

2) 재설계 시간이 단축

- 테스트 코드를 작성하면서 인터페이스나 클래스의 구조를 많이 수정 하게 되는데, 이것이 실제 구현 코드를 작성하면서 이 작업을 할 경우에 구현 하고 있는 코드를 또한 고쳐야 하는 문제를 유발하게 된다.

3) 디버깅 시간의 단축

- 각각의 모듈 별로 테스트를 자동화 할수 있는 코드가 있다면 오류 발생시 모든 레이어들을 전부다 디버깅할 필요 없이 자동화 된 유닛테스팅 결과로 손쉽게 찹아 낼 수 있다.

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

- 단순 통합테스트 문서를 만들게 되면 내부적인 하나하나의 로직이 어떻게 테스트 되었는지 제공할 수 없다.

- TDD를 하게 될 경우, 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.

5) 추가 구현의 용이함

- 추가 기능을 개발할 경우 기존의 코드들에 얼만큼 영향을 미치게 될지 모르기 때문에 다시 모든 코드들을 테스트 해야 하는 어려움이 있다.

- 유닛 테스트로 자동화 될 경우에 우리는 수동으로 모든 테스트를 다시 진행해야 되는 시간적인 낭비를 줄일 수 있다.

3. TDD의 단점

1) 코드 생산성

- 코드 퀄리티 보다 빠른 결과물을 원하는 환경이라면 쉽게 도입이 어려울수 있다.(SI 프로젝트)

- 개발자들이 TDD를 공부해야 하고, 추가적으로 테스트 코드를 작성해야 하기 때문이다.

2) 테스트가 어려운 예외가 발생할 경우, 테스트를 만들기 위해 기존 구현 코드의 구조를 변경해야 하는 일이 발생 할수 있으므로, 테스트를 만들기 위해 더 많은 수정이 필요한 경우가 생길수 있다.

[참고사이트]

http://www.hoons.net/Lecture/View/644