TDD 란?

TDD , 즉 테스트 주도 개발(Test Driven Development)이다. 소프트웨어 개발 방법론 중의 하나로, 선 개발 후 테스트 방식이 아닌 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다. 다시 말해 먼저 자동화된 테스트 코드를 작성한 후 테스트를 통과하기 위한 코드를 개발하는 방식의 개발 방식을 말한다.

TDD에 대한 프로그래머들의 의견은 엇갈린다고 한다. TDD의 실효성을 업무로 경험한 사람들은 TDD를 더 효과적으로 실무에 적용 하기 위해 고민한다. 반면, 회사마다 일하는 방식이나 처한 업무 환경에 편차가 있다보니 일각에서는 실무에서 TDD를 사용하는 건 사실상 현실과 괴리감이 크다는 의견도 있다.

TDD란?

테스트 주도 개발(TDD)은 소프트웨어를 개발하는 여러 방법론 중 하나이다. 제품이 오류없이 정상 작동하는지 확인하기 위해 모든 코드는 프로그래머가 작성하고 나서 세트스를 거치게 된다. TDD에서는 제품의 기능 구현을 위한 코드와 별개로, 해당 기능이 정상적으로 움직이는지 검증하기 위한 테스트 코드를 작성한다. 이를 통해 테스트가 실패할 경우, 테스트를 통과하기 위한 최소한으로 코드를 개선한다. 최종적으로 테스트에 성공한 코드를 리팩토링 하는 과정을 거친다.

TDD를 이용한 개발방법

1. 테스트 케이스를 작성
2. 테스트 케이스를 통과하는 코드 작성
3. 작성한 코드 리팩토링

먼저 테스트 케이스와 테스크 코드를 작성한다. 테스트 코드가 개발을 주도하기 위해서는 반드시 실패를 포함하는 테스트 코드의 작성이 앞어샤 한다. 다음으로는 테스트 케이스를 통과하는 코드를 작성한다. 작성된 코드는 개선될 수 있는 많은 여지를 포함하는 코드이다. 마지막 리팩토링 단계에서 이를 개선한다.

TDD는 기본적으로 위 3단계의 반복으로 진행하며 점진적으로 개발이 진행된다. 필요한 단위 기능에 대한 테스트 코드를 먼저 작성한 후 테스트를 통과하도록 코드를 작성하는 것이다.

TDD의 장점

객체 지향적인 코드 개발

TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능별로 모듈화가 이루어진다.
이는 의존성과 종속성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며, 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.

설계 수정시간의 단축

테스트코드를 먼저 작성하기 때문에 최초 설계안을 만족하게 하며 입출력 구조와 기능의 정의를 명확하게 하게 되므로 설계의 구조적 문제를 바로 찾아낼 수 있다.

유지보수(리팩토링)의 용이성

기본적으로 단위 테스트 기반의 테스크 코드를 작성하기 때문에 추후 문제가 발생하였을 때 각각의 모듈별로 테스트를 진행해보면 문제의 지점을 쉽게 찾을 수 있다.

테스트 문서의 대체 가능

대부분의 개발 프로젝트에서 테스트를 진행하는 경우 단순 통합 테스트에 지나지 않는다. TDD를 하게 될 떄 테스팅을 자동화시킴과 동시에 더욱 정확간 테스트 근거를 산출해 정의서를 작성할 수 있다.

TDD의 단점

사전준비 기간

TDD를 프로젝트에 도입하려면 사전에 필요한 지식을 습득하고 개발 환경을 구축해야 한다. TDD를 효과적으로 사용할 수 있는 수준으로 개발자를 교육하는데 보통 1~6개월간의 시간이 필요하다.

생산성 저하

프로젝트를 진행할 때 경험 때문에 어떤 예외상황이 발생할지 눈에 뻔히 보이는 경우가 종종 있다. 이러한 단발성 개발은 개발 기간이 타이트하게 잡히는 경우가 많다. 이럴 때 TDD를 이용해 테스트 코드를 작성하고 그에 통과하기 위한 콛즈를 작성한다면 비효율적일 것이다.

TDD 효과는??

1. 코드가 내 손을 벗어나기 전에 가장 빠른 피드백을 받을 수 있다.

개발 프로세스에서는 보통 '인수 테스트'를 한다. 이미 배치된 시스템을 대상으로 클라이언트가 의뢰한 소프트웨어가 사용자 관점에서 사용할 수 있는 수준인지 체크하는 과정이다. 이미 90% 이상 완성된 코드를 가지고 테스트하기 때문에 문제를 발견할 수는 있다. 다만, 정확하게 원인이 무엇인지 진단하기는 힘들다.

TDD를 사용하면 기능단위로 테스트를 진행하기 때문에 코드가 모두 완성되어 프로그래머의 손을 떠나기 전에 피드백을 받는 것이 가능하다.

2. 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다.

켄트 백은 TDD는 불안함을 지루함으로 바꾸는 마법의 돌이라고 말했다. 앞서 말한 것처럼 TDD를 사용하면, 코드가 내 손을 떠나 사용자에게 도달하기 전에 문제가 없는지 먼저 진단 받을 수 있다. 그러므로 코드가 지닌 불안정성과 불확실성을 지속적으로 해소해준다.

3. 프로그래머의 오버 엔지니어링을 방지한다.

TDD는 사실 지루한 작업이다. 그렇다 보니, 프로그래머들은 간혹 계획하지 않았던 코드를 추가하여 오버 엔지니어링 하는 경우가 있다. 하지만 TDD의 원칙중 하나는, 테스트를 통과하기 위한 최소한의 코드만 작성 및 개선해야 한다는 것이다. 기능 단위로 테스트를 진행하기 때문에 문제가 발견되지 않은 코드에 영향을 줄 수 있는 오버 코딩은 하지않는다.

4. 개발 과정이 테스트 코드로 남기 때문에, 과거 의사결정을 쉽게 상기할 수 있다.

TDD를 사용하면, 테스트 코드를 작성하는 과정에서 히스토리가 남는다. 어떻게 보면 과거의 나 자신과 프로그래머가 협업하는 것을 용이하게 만들어준다고 할 수 있다. TDD를 통해 작성한 테스트 코드를 트래킹하면서 과거에 어떤 인과관계로 의사결정을 했는지 확인하기 쉽다.

그래서 TDD는 필요한 것인가??

TDD를 들으면 매우 유용할 것 같은 느낌을 받는다. 하지만 TDD가 실제로 많이 쓰이는가? 이 질문에는 확답을 할 수 없다고 한다.
TDD는 비용적인 측면에서 고민해야 한다는 것이다. 테스트 코드를 짜는 것 또한 엄연한 개발이다. 그만큼 시간을 투자함에 따라 이익을 얻어야 하는 테스트에만 너무 과도하게 몰입해버린다면 그야말로 시간 낭비가 될 것이다.

결론적으로 적당한 TDD는 개발에 있어 능률 상승을 가져올 수 있다. 하지만 과도한 테스트는 오히려 해롭다.








참고
(https://media.fastcampus.co.kr/knowledge/dev/tdd/)
(http://www.incodom.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C)