[기타] TDD

TDD

• 테스트 주도 개발 : 테스트가 개발을 이끌어 나간다

• 구체적인 행동 레벨에서의 TDD
  • 테스트를 먼저 만들고 그 테스트를 통과하기 위한 코드를 짜는 것
• 추상적인 레벨에서의 TDD
  • 결정과 피드백 사이의 갭을 조절하기 위한 테크닉
  • 결정
    • 이 방법으로 해야지, 이 부분은 이걸 이용해서 짜야지 등을 결정
  • 피드백
    • 프로그램을 하다보면 성공/실패라는 피드백을 받는다.
  • 이 둘 사이의 갭이 생긴다
    • 갭이 커질수록 문제
    • 갭을 모르면 더 큰 문제
    • 따라서 결정했을 때의 코드를 테스트 프로그램을 실행한 결과로 성공/실패라는 프로그램 상의 피드백을 받아야 하고 그 둘 사이의 갭을 내가 인식한다면 TDD를 하고 있는 것이다.
• TDD를 왜 해야 할까?
  • 불확실성이 높을 때 피드백과 협력이 중요하기 때문에 TDD가 도움이 된다.
• 어떤 상황에서 해야할까?
  • 처음해보는 프로그램 주제
    • 나에 대한 불확실성이 높은 경우
  • 고객의 요구조건이 바뀔 수 있는 경우
    • 위부적인 불확실성이 높은 경우
  • 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
  • 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
  • 불확실성이 높을 때 TDD를 하면 된다.
• 효과
  • 피드백
    • TDD를 하면 피드백이 증가한다.
  • 협력
    • TDD에서 테스트는 명사로서 record로 남을 수 있다. 따라서 이것을 공유하기가 쉬워진다.
    • 공유를 함으로써 협력이 증진된다.
      • 코드를 빠르고 쉽게 이해할 수 있다.
• 장점
  • 피드백과 협력을 증진시키기 때문에 불확실성에 대해 대비를 하게 해준다.
  • 결함이 1/2 ~ 1/10까지 줄어든다.
  • 코드 복잡도가 떨어진다.
• 단점
  • 개발 시간이 10 ~ 30% 늘어난다.
  • TDD를 사용하지 않은 개발자의 경우 개발하는 방식을 많이 바꾸어야 한다.