TDD(Test Driven Development)란 ?

TDD의 정의

Test Driven Development (테스트 주도 개발)
테스트가 개발을 이끌어 나간다.

구체적인 행동 레벨에서의 TDD의 개념

테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것 즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다.

• 보통은 SW 개발을 할 때 코딩이 다 끝나고 난 후 테스트를 한다.

• TDD를 적용한 사례
  예를 들어, 생년월일(input)을 입력받으면 현재 나이(output)을 출력하는 프로그램

  1. 처음에는 간단한 것으로 목표를 정한다. (태어난 해와 올해의 연도를 입력)
  2. 만들기도 전에 만든 후에 무엇을 테스트할지를 설계한다.
  3. 그 다음에 그 테스트를 통과할 프로그램을 만든다.
  4. 테스트 프로그램으로 이 프로그램을 실행한다.
  5. 통과했으면 새로운 테스트를 추가한다.

위와 같은 작업을 계속 반복하면서 수행한다.

TDD를 왜 해야할까

불확실성이 높을 때 '피드백'과 '협력'이 중요하다.

• 피드백과 협력이 중요한 이유

  1. 불확실성이 높을 때 '피드백'과 '협력'을 이용하면 더 좋은 결과가 나올 확률이 높아진다.
  2. TDD도 마찬가지로 '피드백'과 '협력'을 증진시키는 것이기 때문에 불확실성이 높을 때 도움이 되는 것이다.

TDD는 어떤 상황에서 해야할까

• 만약 어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 뻔하다면 TDD를 하지 않아도 된다.
• 또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 된다.
• 그렇다면 TDD는 어떤 상황에서 해야할까 ?

1. 처음해보는 프로그램 주제 (나에 대한 불확실성이 높은 경우)
2. 고객의 요구조건이 바뀔 수 있는 프로젝트 (외부적인 불확실성이 높은 경우)
3. 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
4. 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우

TDD의 효과

모든 애자일의 실천법은 피드백과 협력을 동시에 증진시킨다.

1. 피드백

• TDD를 하면 피드백이 증가한다.
  테스트를 통과하는 것으로 잘되고 있는가를 자주 확인할 수 있다.
  이 부분은 사람들이 쉽게 느낄 수 있다.

2. 협력

• 테스트 코드에는 개발자의 개발 과정(어떤 고민/어떤 의사결정)이 나와있다.
• 앞의 TDD의 정의와 같이 테스트 코드를 보면 그 사람의 의사결정이 나타나고 상대방은 그 부분은 왜 그렇게 짰는지를 쉽고 빨리 알게 되기 때문에 협력이 증진된다.

TDD의 장점

1. 피드백과 협력을 증진시키기 때문에 불확실성에 대해 대비를 하게 해준다.
2. TDD를 하면 결함이 줄어든다.
3. TDD를 하면 코드 복잡도가 떨어진다.

TDD의 단점

1. TDD를 하면 개발 시간이 늘어난다.