TDD (Test Driven Devlopment)

• TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 함
• 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현

TDD 개발 방식

• TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점
  • 디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야 함
  • 테스트 코드를 작성하는 도중에 발생하는 예외 사항(버그, 수정사항)들은 테스트 케이스에 추가하고 설계를 개선
  • 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성
• 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해짐
• 또한, 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감됨

TDD 개발 방식의 장점

보다 튼튼한 객체 지향적인 코드 생산

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

재설계 시간의 단축

• 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됨
• 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있는데 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있음

디버깅 시간의 단축

• 유닛 테스팅을 하는 이점이기도 함
  • 예를 들면 사용자의 데이터가 잘못 나온다면, DB의 문제인지 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야함
  • 하지만 TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손쉽게 찾아낼 수 있음

테스트 문서의 대체 가능

• 주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만들지만 이것은 단순 통합 테스트 문서에 지나지 않음
• 하지만 TDD를 하게 될 경우 테스팅을 자동화시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있음

추가 구현의 용이함

• 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것
• 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있음

TDD의 효과

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

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

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

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

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

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

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

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

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

TDD 개발 방식의 단점

가장 큰 단점은 바로 생산성의 저하

• 개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 하는 경우가 많음
  • 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문
• TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어남
• SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않음

TDD에 관한 편견과 실상

TDD는 무조건 해야 한다?

• 그렇지 않다

• TDD가 프로그래머에게 주는 이점에 대해 나열하면 TDD가 모두에게 필요한 것처럼 느껴질 수 있지만 프로그래머가 코드를 작성해 기능 하나를 추가할 때마다 시간이 늘어난다고 본다면 TDD는 오히려 비효율적인 것처럼 보이기도 함
  • TDD를 사용했을 때의 초기 비용은 TDD를 사용하지 않았을 때보다 크기 때문
  • 운영 코드를 테스트하기 위한 코드를 프로그래머가 따로 작성해야 한다는 점만 보아도 알 수 있음
• 그러므로 프로그래머는 하나의 프로젝트를 완성하는데 걸리는 예상 일정과 자원을 고려해야 하며 이에 따라 TDD를 사용할 수도, 사용하지 않기로 결정할 수도 있음

• 물론 TDD를 사용하면 일정 시점을 지나면 TDD를 사용하지 않을 때와 비교하여 시간 대비 비용이 더 커지지 않고 일정하게 유지됨
  • 즉, TDD를 사용하기 시작하면 초기 비용은 더 많이 들 수 있으나 전체적으로 봤을 때 비용이 점진적으로 늘어나지 않는다는 것

• 따라서, TDD를 위한 환경세팅이 이미 잘 되어 있는 업무 환경이라면 TDD를 사용하는 편이 장기적으로는 효과적이라 할 수 있음

TDD는 버그를 박멸한다?

• 그렇지 않다

• TDD는 버그를 없애주는 도구가 아니기 때문이며 오히려 TDD를 사용하면 더 많은 버그를 사전에 발견할 수 있음
• 프로그래머가 작성한 코드가 사용자에게 도달하기 전에, 혹은 전체 코드를 완성하기 전에 기능 단위로 문제를 개선할 수 있게끔 빠른 피드백을 전달하는 것
  • 그래서 버그를 보다 빠르고 효과적으로 개선할 수 있도록 프로그래머를 도와줄 수는 있음

TDD는 항상 느리다?

• 그렇지 않다

• TDD를 업무에 사용할 때 업무 속도가 느려진다고 느끼는 것에는 여러 이유가 있음
• TDD를 처음 도입하면 TDD를 사용하기 위해 필요한 초기 자원이 미진해서 속도가 나지 않는다고 생각할 수 있음
• 혹은 회사에서 여러 프로그래머가 협업해야 하는 경우, TDD를 사용하기 위한 업무 프로세스가 익숙하지 않아 개발 속도가 느려진다고 느끼기도 함

• 테스트 코드 작성에 대한 업무 부담감도 한 몫 함
• 테스트 자동화를 위해 필요한 코드까지 프로그래머가 작성하고 관리해야 하므로 업무가 오히려 더 늘어나 비효율적이라 여길 수 있음
• 기억해야 할 것은 TDD 자체가 목적이 되어서는 안 된다는 사실이며 TDD는 공동의 목표를 효율적으로 달성하기 위한 도구

TDD를 하기 어려운 이유

• 이제까지 자신이 개발하던 방식을 많이 바꿔야 함
  • 몸에 체득한 것이 많을 수록 바꾸기가 어려움
  • 오히려 개발을 별로 해보지 않은 사람들에겐 적용하기 쉬움

• TDD는 이렇게 해야된다는 이미지/틀이 있음
  • 반드시 툴(단위 테스트 프레임워크)을 써서 개발해야 된다고 생각함
  • 이러한 규칙에 얽매이는 것은 애자일 방식이 아니라고 생각함
  • 결국엔 규칙에 얽매여 똑같은 테스트를 copy&paste함
  • 도구/규칙에 집착하다 보니, TDD가 어려워지는 것

테스트 기법의 종류와 장단점

1. 수동 테스트

• 회사에서는 보통 QA라고 부르는 전문 담당자들이 UI를 활용해 기능을 검증
  • 사람이 검증하기 때문에 사용자와 가장 가까운 관점에서 테스트가 가능하며 소프트웨어의 모든 코드가 현장에 배치된 후에 테스트할 수 있음
• 따라서 어떤 기능이 정상 작동하기 위해 필요한 모든 코드가 준비되어야 하며 가장 온전한 전체 코드를 검증하는 테스트 방식

• 단점은 실행 비용은 높은데 결과 변동이 크다는 점
• 전문성을 지닌 담당자가 비용을 줄이기 위해 노력하지만 휴먼 에러의 가능성을 완전히 없애기는 어려움
• 또한 시간이 흐르면서 추가되는 기능은 자연스럽게 증가하는데, 문제는 어떤 기능을 추가하거나 개선하기 위해 작성한 코드는 다른 코드에 영향을 미친다는 점
• 그래서 테스트를 진행하더라도 새로 추가된 코드로 인해 영향을 받을 기존 코드에 대한 테스트는 건너뛰거나 충실히 진행하지 못하는 경우가 많음

2. 테스트 자동화

• 수동 테스트가 지닌 한계를 보완하기 위해 등장한 도구
• 사람이 직접 테스트하지 않고 어떤 기능을 검증하는 또 다른 코드를 작성하는 방식

• 단점은 수동 테스트에 비해 프로그래머가 더 많은 코드를 작성해야 한다는 점
• 운영 코드를 테스트하기 위한 별도의 코드를 추가 작성해야 하기 때문에 테스트 코드의 작성과 관리가 프로그래머 개인의 역량에 달려 있어, 업무 자체가 허들이 될 수도 있음

• 반면, 테스트에 드는 비용은 매우 낮아진다는 점이 장점
• 휴먼 에러의 가능성도 줄어들기 때문에 수동 테스트에 비해 테스트 자체에 대한 신뢰도는 매우 높아짐

3. 인수 테스트

• 배치된 시스템을 대상으로 검증하는 방식으로 주로 클라이언트가 의뢰한 소프트웨어를 최종적으로 사용할 수 있는 수준인지 점검하는 테스트
• 전체 시스템의 이상 여부가 없는지 확인하며 사용자 관점으로 체크하기 때문에 신뢰도가 높은 테스트 방법

• 단, 비용이 매우 높으며 코드 작성부터 관리, 테스트 실행까지 자원이 많이 들어감
• 또한 문제는 파악할 수 있으나, 그 원인까지 단번에 알려주지는 못하기 때문에 프로그래머 입장에서 받을 수 있는 피드백의 질이 떨어짐

4. 단위 테스트

• 인수 테스트의 단점을 보완하는 검증 방식이며 단위 테스트는 시스템의 일부(하위 시스템)를 대상으로 기능을 검증하는 테스트
• 전체 시스템을 배치해놓고 진행하지 않으므로 비용이 상대적으로 낮은 편

• 인수 테스트와 비교해서 단위 안에서 버그가 있다는 걸 상대적으로 자세히 알 수 있기 때문에 프로그래머 입장에서는 문제 해결을 위해 필요한 피드백을 적절하게 받을 수 있음
• 하지만 전체 시스템의 이상 여부를 판단하는 신뢰도는 낮아짐
  • 단위 테스트에서 문제가 없다고 판단되어도 전체 시스템이 유기적으로 연결될 때 오류가 날 수도 있기 때문