테스트 주도 개발

#!if 넘어옴1 != null
'''TDD'''{{{#!if 넘어옴2 != null
, ''''''}}}{{{#!if 넘어옴3 != null
, ''''''}}}{{{#!if 넘어옴4 != null
, ''''''}}}{{{#!if 넘어옴5 != null
, ''''''}}}{{{#!if 넘어옴6 != null
, ''''''}}}{{{#!if 넘어옴7 != null
, ''''''}}}{{{#!if 넘어옴8 != null
, ''''''}}}{{{#!if 넘어옴9 != null
, ''''''}}}{{{#!if 넘어옴10 != null
, ''''''}}}은(는) 여기로 연결됩니다. 

#!if 설명 == null && 리스트 == null
{{{#!if 설명1 == null
다른 뜻에 대한 내용은 아래 문서를}}}{{{#!if 설명1 != null
{{{#!html 풀 메탈 패닉의 TDD-1}}}에 대한 내용은 [[투아하 데 다난(풀 메탈 패닉!)]] 문서{{{#!if (문단1 == null) == (앵커1 == null)
를}}}{{{#!if 문단1 != null & 앵커1 == null
의 [[투아하 데 다난(풀 메탈 패닉!)#s-|]]번 문단을}}}{{{#!if 문단1 == null & 앵커1 != null
의 [[투아하 데 다난(풀 메탈 패닉!)#|]] 부분을}}}}}}{{{#!if 설명2 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단2 == null) == (앵커2 == null)
를}}}{{{#!if 문단2 != null & 앵커2 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단2 == null & 앵커2 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명3 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단3 == null) == (앵커3 == null)
를}}}{{{#!if 문단3 != null & 앵커3 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단3 == null & 앵커3 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명4 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단4 == null) == (앵커4 == null)
를}}}{{{#!if 문단4 != null & 앵커4 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단4 == null & 앵커4 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명5 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단5 == null) == (앵커5 == null)
를}}}{{{#!if 문단5 != null & 앵커5 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단5 == null & 앵커5 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명6 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단6 == null) == (앵커6 == null)
를}}}{{{#!if 문단6 != null & 앵커6 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단6 == null & 앵커6 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명7 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단7 == null) == (앵커7 == null)
를}}}{{{#!if 문단7 != null & 앵커7 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단7 == null & 앵커7 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명8 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단8 == null) == (앵커8 == null)
를}}}{{{#!if 문단8 != null & 앵커8 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단8 == null & 앵커8 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명9 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단9 == null) == (앵커9 == null)
를}}}{{{#!if 문단9 != null & 앵커9 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단9 == null & 앵커9 != null
의 [[#|]] 부분을}}}}}}{{{#!if 설명10 != null
, {{{#!html }}}에 대한 내용은 [[]] 문서{{{#!if (문단10 == null) == (앵커10 == null)
를}}}{{{#!if 문단10 != null & 앵커10 == null
의 [[#s-|]]번 문단을}}}{{{#!if 문단10 == null & 앵커10 != null
의 [[#|]] 부분을}}}}}}

#!if 설명 == null
{{{#!if 리스트 != null
다른 뜻에 대한 내용은 아래 문서를}}} 참고하십시오.

#!if 리스트 != null
{{{#!if 문서명1 != null
 * {{{#!if 설명1 != null
풀 메탈 패닉의 TDD-1: }}}[[투아하 데 다난(풀 메탈 패닉!)]] {{{#!if 문단1 != null & 앵커1 == null
문서의 [[투아하 데 다난(풀 메탈 패닉!)#s-|]]번 문단}}}{{{#!if 문단1 == null & 앵커1 != null
문서의 [[투아하 데 다난(풀 메탈 패닉!)#|]] 부분}}}}}}{{{#!if 문서명2 != null
 * {{{#!if 설명2 != null
: }}}[[]] {{{#!if 문단2 != null & 앵커2 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단2 == null & 앵커2 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명3 != null
 * {{{#!if 설명3 != null
: }}}[[]] {{{#!if 문단3 != null & 앵커3 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단3 == null & 앵커3 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명4 != null
 * {{{#!if 설명4 != null
: }}}[[]] {{{#!if 문단4 != null & 앵커4 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단4 == null & 앵커4 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명5 != null
 * {{{#!if 설명5 != null
: }}}[[]] {{{#!if 문단5 != null & 앵커5 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단5 == null & 앵커5 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명6 != null
 * {{{#!if 설명6 != null
: }}}[[]] {{{#!if 문단6 != null & 앵커6 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단6 == null & 앵커6 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명7 != null
 * {{{#!if 설명7 != null
: }}}[[]] {{{#!if 문단7 != null & 앵커7 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단7 == null & 앵커7 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명8 != null
 * {{{#!if 설명8 != null
: }}}[[]] {{{#!if 문단8 != null & 앵커8 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단8 == null & 앵커8 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명9 != null
 * {{{#!if 설명9 != null
: }}}[[]] {{{#!if 문단9 != null & 앵커9 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단9 == null & 앵커9 != null
문서의 [[#|]] 부분}}}}}}{{{#!if 문서명10 != null
 * {{{#!if 설명10 != null
: }}}[[]] {{{#!if 문단10 != null & 앵커10 == null
문서의 [[#s-|]]번 문단}}}{{{#!if 문단10 == null & 앵커10 != null
문서의 [[#|]] 부분}}}}}}

1. 개요

2. 상세

1. 개발에 적용할 수 있을 수준의 구체적인 요구사항을 작성하는 것이 매우 어려움. 불가능함.
2. 규모가 커질수록 설계에 요구되는 시간과 비용이 기하급수적으로 증대됨.
3. 실제로 개발에 들어가고나서 정해진 요구사항이 변경되거나, 다양한 문제점이 발견됨.
4. 위와 같은 문제로 인해 작업 난이도 및 개발일정을 예측하는 것이 어려움.

3. 분류

3.1. 단위 테스트

3.1.1. stub, mock

3.2. 통합 테스트

3.3. 인수 테스트

4. 장점

• 코드의 유지보수가 용이해진다
  프로그래밍 개발에서는 처음 개발할 때보다 이미 개발한 코드의 버그를 수정하고, 최적화하고, 새 기능을 추가할 때 비용이 더 들어간다. 그런데 테스트를 작성하면 코드에 절대로 뒤떨어지지 않는 문서가 탄생하며, 다른 코드의 행위가 보증되므로 원하는 부분에만 신경을 쓸 수 있으며, 테스트하기 쉬운 코드는 자연히 품질이 높아지므로 다시 읽기도 편하다. 또한 테스트가 있으면 안심하고 코드를 리팩토링할 수 있다.
• 빠른 피드백
  새 코드를 작성한 다음 기능에 문제는 없는지, 타입을 잘못 설정하지는 않았는지, edge case에 대한 문제는 없는지를 확인하기 위해서는 일반적으로 해당 코드가 병합되고, 실제 제품에 통합될 때까지 기다려야 한다. 반면 테스트를 작성하면 코드가 통합되기 전, 배포되기 전에도 문제 있는 기능에 대한 피드백을 받을 수 있고 이는 TDD와 애자일에서 말하는 '피드백 시간의 단축' 원칙과 정확하게 부합하는 사례이다. 개별 단위의 피드백 주기가 빨라질수록, 큰 기능의 피드백 소모 시간 역시 사전 피드백으로 단축된 시간에 비례하게 줄어들기 때문.
• 디버깅 시간 단축
  테스트를 작성하는 시간을 포함시키고도 오히려 전체 작업 시간은 줄어든다. 흔히 코드를 작성하는 시간이 작업 시간의 전부라고 착각하기 쉬우나, 현실은 대부분의 시간이 디버깅에 투입된다. 이 때 테스팅은 디버깅을 해야 할 범위를 단위(unit) 안으로 제한함으로써 디버깅에 들어가는 노고를 크게 줄여준다. 예시로 테스트가 없었다면, 만약 완성된(integrated) 제품을 실제로 가동시켰을 때 버그가 포착된 경우, 어떤 경로(trace)로 버그가 발생하는지, 즉 어떤 코드가 근본적인 버그의 원인(cause)인지를 거슬러 올라가는 작업부터 시작해야 한다. 반대로 테스트를 사용한다면 #6번, #17번, #44번 테스트가 결과값이 예상과 달라 실패한 것을 보고 여기서부터 시작하여 디버깅 시간을 압도적으로 단축할 수 있다.
• 문서화(test as a documentation)
  테스트를 작성하는 것 자체가 훌륭한 문서화이기도 하다. 소스 코드 중간중간의 주석은 왜 코드가 이렇게 짜여져 있는지를 기록한다면, 유닛 테스트는 코드가 어떻게 행동(behave)해야 하는지를 기록한다. 따라서 다른 프로그래머들이 쓴 (또는 과거의 자신이 쓴) 코드를 파악하고 프로그램을 수정, 확장하는데 시간과 비용이 크게 단축된다.

5. 한계 및 비판

• 인간은 예측하지 못한 실수를 사전에 떠올릴 수 없다
  현실적으로 테스트 케이스를 미리 작성하고 구현을 시작한다는 것은 이미 해당 실수가 일어날 수 있다고 명확히 인지하고 있는 상황에서나 적용 가능한 이야기다. 대표적으로 결과가 확정되어 있는 수학 라이브러리 코드 등이 이에 속한다. 일례로 루트를 계산할 때 뉴턴-랩슨 방법보다 빠른 방법을 구현하기 위해 코드를 작성한다면, 그 결과 값은 항상 기존의 정답과 같아야 한다. 그렇기 때문에 몇몇의 예외 케이스들을 테스트한다면 해당 문제를 잡고, 새 구현이 잘 동작함을 귀납적으로 검증할 수 있다.
  
  하지만 이같은 특수한 경우가 아닌 대부분의 프로그래밍 사례에서는 미리 작성된 테스트가 개발자의 실수를 답습하기만 한다. 즉 변명을 하기 위한 완벽한 변명거리가 된다. 기본적으로 인간의 실수는 코드를 작성할 때 인지할 수 없다. 코드를 쓰고 문제가 발생 했을 때 테스트를 작성하나, 테스트를 작성하고 코드를 작성하고 문제를 발견하나 결국 발생할 실수는 똑같이 발생하기 때문이다. 장점으로 알려진 디버깅 시간 단축은 그저 이론적인 환상에 가깝다.
• 테스트가 모두 통과하므로 버그가 없다고 생각하는 함정에 빠질 수 있다
  녹색 불이 들어오면서 통과하는 정돈되고 멋진 전체 테스트 목록은 개발자에게 높은 쾌감과 확신을 준다. 이 때문에 꽤 잘 갖추어진 테스트 목록이 완성되면, 개발자는 섣불리 코드를 확신에 차서 배포하다가 테스트에서는 고려하지 못한 문제를 만나 버그를 만들고 당황하기도 한다.
  
  그러나 테스트의 존재는 1. 구현 코드에 버그가 없고, 2. 구현 코드가 고객의 비즈니스 요구사항을 완벽히 만족시킨다는 것을 보장하지 않는다. 개발자는 구현할 로직의 모든 스펙과 부작용을 완벽히 예측할 수 없고, 비즈니스 요구사항은 계속 변화한다. 어제까지 완벽했던 코드는 오늘 협력사의 업데이트로 인해 무너질 수 있다. 오늘까지 맞았던 로직은 내일 회사의 목표나 고객의 변심에 의해 틀릴 수 있다. 테스트와 테스트 주도 개발은 "이 구현 코드가 문제없이 완벽함"을 보증하는 것이 아니라 "이 구현 코드가 여기까지는 문제없음을 확인함"을 보증하는 것이다. "여기까지는 괜찮음"을 확인한 것만으로도, TDD는 제 역할을 한 것이다. 테스트를 중심으로 개발한 덕분에 개발자는 새로운 변경을 만들 때 전체 소프트웨어가 문제가 없는지를 처음으로 돌아가서 점검할 수고를 덜기 때문이다.
• 과테스트(overtesting)
  개별 함수 하나하나, 사소한 기능 하나하나마다 테스트를 작성하는 경우로, 결과적으로는 프로젝트 진행에 아무런 도움이 안 되는 시간 낭비 행위이다. 이러한 문제가 발생하는 원인은 근본적으로 단위(unit) 설정의 실패로, 최소한의 독립성이 존재하는 기능적 덩어리가 아니라 그저 코드 한줄 한줄을 비의미적으로 쪼개서 잘못 보고 있는 것이다. 흔히 코드베이스 전체의 테스트 커버리지를 굳이 100%로 채우려고 시도하거나 위에서 설명한 대로 성공하는 테스트로 인한 착각성 만족감에 도취된 경우로, 이러한 과테스팅의 문제점은 켄트 벡 역시 경고한 것이 있다.
  
  특히나 이렇게 의미적 경계를 무시한 테스트가 늘어나면 추후 코드 구조를 개선할 때나 리팩토링을 할 때도 기존 테스트를 대거 수정해야 하는 등, TDD의 장점을 전혀 살리지 못하고 오히려 개발에 발목을 잡게 된다. 현실적으로, 우선순위를 설정하여 도메인 코드를 최우선으로 테스트하고 누가 봐도 자명하거나 주요 도메인이 아닌 계층은 테스트 작성을 건너뛰거나 우선순위를 낮추는 것이 좋다.
• 커버리지 중복(overlapping overage)
  테스트의 단계별 종류가 일종의 집합과 같은 계층적 구조를 형성하기 때문에 기인하는 문제로, 하위 계층에서 충분히 테스트 된 내용을 상위 계층에서 또다시 테스트하기 때문에 발생하는 중복을 말한다. 예를 들어 상위 계층에서의 입력이 부분적으로 하위 계층으로 전달 또는 주입되는 경우, 단위 테스트 등으로 충분히 여러 케이스들을 검증한 상태라면 상위 계층 테스트에서도 이를 구태여 번복할 필요는 없다.
  
  예를 들어 비밀번호 입력 컴포넌트에서 '영문 대소문자, 특수문자가 없다면 입력 불가' 등의 요구사항과 각종 테스트 케이스들을 검증했다면, 이를 회원가입 페이지, 로그인 페이지, 비밀번호 초기화 페이지 등 모든 상위 계층에서 또다시 검증할 필요는 없다는 것. 물론 한다고 나쁜 건 아니지만, 이게 반복된다면 이미 검증된 커버리지 영역을 계속 덮어씌우는 것과 같기에 불필요하고, 추후 요구사항 변경시 함께 수정해야 하는 테스트가 늘어난다. 당장의 개발이 바쁘다면, 대부분의 검증은 유닛 단계에서 마무리하고 통합 테스트 이후부터는 몇몇개의 happy path만 테스트하는 것이 시간 비용상 현실적이다.
• 버려지는 테스트
  테스트는 기능이 이나리 기능을 묘사(describe)하고 검증하기 위한 부수적 존재이므로, 비즈니스 로직이나 요구사항에 변동이 발생하면 항상 이를 추적하며 따라가야 한다. 기존 기능의 목적과 형식에 맞게 테스트 케이스들과 데이터 등을 작성하였다면 기능이 변경되었을 때 실패하는 기존 테스트 케이스들을 지우고 새 요구사항에 맞는 테스트 케이스들을 다시 새로 만들기 위해 많은 시간을 소모해야 한다.
  
  기능에서 테스트를 도출하고, 테스트에서 코드를 구현하는 TDD의 이론적 위계를 따르면, 코드의 변화로부터 기능을 보호할 수는 있지만 기능의 변화로부터 테스트를 보호하는 것은 근본적으로 불가능하다. 요구사항이 수시로 바뀌는 환경이라면 이상적인 TDD 이론은 테스트 코드의 유지보수 비용을 증가시켜 역효과를 낼 가능성도 있으므로, 도입에 신중해야 한다.
• 종속성 분리에 소모되는 시간
  테스트하고자 하는 코드가 순수 도메인 로직이 아니라 네트워크, 데이터베이스, 시간 등 불순수한 종속성과 강하게 엮여 있다면, 단위 테스트 시 이를 일일히 분리하고 mocking하는 과정에서 의외로 많은 시간이 소모된다. 물론 이론적으로는 그러한 기술적 부채를 줄이는 것이 옳으나, 현실적으로 대부분의 코드는 일정 부분 이상 떼어내기 힘든 종속 관계를 이용하고 있고, 이를 일일히 injection 패턴으로 분리해내는 것은 정말로 많은 시간을 소모한다. 코드가 naive하면 테스트가 어려워지고, 테스트하기 좋게 만들면 코드가 복잡해지는 모순이 발생할 수 있다.
• 추가적인 기록물의 증가
  주석의 치명적인 단점은 주석이 항상 코드와 동일한 내용을 보장하지 못한다는 것이다. 쉽게 말하면 소스코드에 쓰여진 주석의 내용과 TDD용으로 개발된 테스트와 실제 라이브 서비스에서 돌아가는 코드와 개발문서가 전부 다를 수도 있다. 추가적인 기록물이 늘어나는 만큼 추후에 읽고 검증해야할 기록물 또한 늘어난다.
• 시간에 쫓기기 쉬움
  모든 일이 그렇듯 테스트를 하면서 개발할 여유조차 주어지지 않는 경우가 생긴다. 시스템 통합의 예를 보면 알겠지만, 대한민국의 소프트웨어 개발 환경은 대부분 TDD는 엄두도 못 낼 정도로 매우 열악한 편이다.

6. 테스팅 프레임워크

• xUnit
  뒤에 -Unit이란 접두사가 붙는 여러 단위(unit) 테스트 프레임워크의 통칭이다. Java의 사실상 표준 테스트 프레임워크인 JUnit이 가장 유명하다. 최초의 xUnit 프레임워크는 SUnit인데, 켄트 벡이 Smalltalk용으로 개발했다. 이후 켄트 벡과 에릭 감마가 함께 이를 Java용인 JUnit으로 포팅했다. 비행기를 같이 타고 가다가 JUnit을 만들었다고 한다. 이 외에도 C++용의 CppUnit, .NET Framework용의 NUnit, XUnit 등이 있다.
• Jest
  자바스크립트용 단위 테스트 프레임워크. Facebook에서 만들었다.

7. 코드 커버리지

• JaCoCo
  Java 코드에 대하여 Code Coverage를 관리할 수 있는 툴이다. Code Coverage를 지원하는 오픈 소스 툴 중에 가장 활성화된 커뮤니티를 가진다.[1] Eclipse, Jenkins, SonarQube에 플러그인 형태로 사용할 수 있으며 NetBeans, IntelliJ IDEA 등의 IDE는 기본적으로 지원하고 있다. Ant, Maven, Gradle 등의 빌드 툴을 사용한다.

8. CI

• Travis CI
• Azure Pipelines
• CircleCI