TDD란?

TDD란 무엇인가?

• 사전적 정의 : 테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화는 테스트 케이스를 작성한다. 그런후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링 한다.

• 짧게 설명하면, 작은 단위의 테스트 케이스를 미리 작성해보고 테스트 중심으로 개발을 한다고 생각하면 된다.

그럼 TDD는 언제 사용하는게 좋을까?

• 만약 이미 해본 프로젝트고, 결과가 뻔하게 나오는 부분은 굳이 테스트 케이스를 작성해봐야 시간낭비일 것이다.
• 그렇다면 TDD는 어느 상황에 했을 때 좋을것인가?
  • 처음 해보는 주제 ( 내가 시행착오를 겪는 범위가 크면 클수록 )
  • 요구사항 혹은 환경이 자주 바뀔 가능성이 큰 프로젝트
  • 개발 중 코드가 많이 바뀌어야 하는 경우
• 중요한 점은 불확실성이 높을 수록 TDD를 하면 좋다.

TDD의 장단점

• TDD를 할 경우 개발시간이 늘어간다
  • CASE BY CASE로 결함과 디버깅 때문에 장기적으로 봤을 때는 줄어들 가능성이 크다고 한다
• TDD는 결함을 줄여준다
  • 결함이 1/2 ~ 1/10까지 줄어든다.
  • SW를 개발하면서 예상하지 못했던 시간을 많이 소요하는 부분이 버그때문이다.
• TDD를 하면 코드 복잡도가 떨어진다
  • 테스트 케이스를 만들면서 통과하면 리팩토링을 하기 때문에 깨끗한 코드가 나온다고 한다.
  • 유지보수 비용이 낮아진다.

그럼 이 좋은 TDD를 대체 왜 안쓰는것인가?

• 개발 시간이 증가한다
  • 단기적인 성과를 내야하거나, 오늘 내일 불을 꺼야하는 기업들은 도입이 어렵다.
  • 많은 기업들이 단기적인 성과에 집중한다.
• TDD가 어렵다
  • 어떠한 툴을 쓰거나, 이렇게 해야 하는 규칙이 있는건 아니다. 개발팀 문화 혹은 나 자신이 개발을 진행할 때 에러를 덜 발생시키게 사전에 방지할 수 있는 방법을 찾는다고 생각해야한다.
  • EX) 매일 아침에 지각을 한다면, 자기한테 맞는 방법으로 일찍 일어나는 방법을 찾아야한다. 남들이 다 알람을 한다고 해서, 내가 알람에 잠이 안깨는데 무슨 소용이 있을까?

TDD를 잘하는 방법

• 나 또한 TDD를 제대로 해보지 않았지만, 결국 개인이든 팀원과 같이 진행하든 일하는 방식이 업그레이드가 되야한다.
• 지속적으로 같은 문제가 발생하지 않도록, 예를 들면 테이블 설계가 문제가 있어, JAVA의 JUNIT으로 테스트를 할때마다 오류라면, 이런 경우는 테이블 설계를 잘 할 수 있는 방법을 찾는게 맞을것이다. TDD를 해도, 저런 경우가 3~4번 계속 반복된다면 무슨
  소용이 있을까? 중복적으로 생기는 문제 혹은 노력들을 자동화 할 수 있는 방법을 찾는게 중요하다고 본다.