TDD

• Test-Driven Development = 소프트웨어 개발 방법론 중 하나로써 테스트 코드를 먼저 작성한 후, 구현 코드 작성 단계와 리팩토링 단계를 짧은 주기로 반복하여 개발하는 방법론

Why TDD

• 단기적, 장기적 목표를 명확히 제시
• 짧은 개발 패턴으로 개발 집중력 UP
• 테스트 코드는 사용설명서 혹은 API 문서로서 팀원간 의사소통의 도구로 활용가능
• 빠른 시간 내 코드의 문제점 파악
• 짧은 개발 사이클로 성취감을 얻어 늘어지지 않을 수 있음

Process

Red = 실패 테스트 작성
Green = 성공 테스트 작성
Refactor = 불필요한 코드 제거

TDD의 오해

비용이 더들고 개발속도를 저하 시킨다???

• 학습에 필요한 기간을 개발 기간으로 계산해서 발생하는 오해
  실제 개발 기간이 길어질 순 있지만, 길어진 시간만큼을 통합과정에서 줄일 수 있음

• 문제 발생 전 예방하는 것이 더 좋음
  진압 시 발생하는 재배포 과정의 비용이 예방을 위한 비용보다 더 높음

TDD != UNIT TEST

• XP (eXtreme Programming)의 대표적인 개발 방법론으로, 테스트 코드를 먼저 작성하고 이를 통과하도록 실제 코드를 작성

• unit test는 검증이 필요한 코드에 대해 테스트 케이스 작성하는 절차 또는 프로세스

시나리오 구성

구현하고자 하는 기능의 테스트 코드를 만듦

• Given : 특정 환경이나 값이 주어졌을 때
• When : 구현하고자 하는 기능을 실행시키면
• Then : 그에 따른 결과가 나와야 함

처음엔 죽을만큼 힘들어도..

성장할 것이라는 선배님들 조언

• 처음 만들었던 테스트들은 코드가 점점 구현 됨에 따라 다양한 상세 테스트들로 인해 역할의 중복이 일어나게 되고, 결국엔 삭제되는 경우도 있음
• 이와 같은 상황에서 단위 테스트는 장렬히 전사했지만, 설계나 구현체의 완성도는 향상 되곤 함
• 더불어 경험에 의한 지식의 수준도 향상 됨을 느낌
• 또한 Mock으로 구현되었던 부분이 실질적 구현체로 대체되는 경우도 다반사
• 테스트가 삭제 되는 것을 아까워 하거나 두려워 하지 마라!

참고 출처

• TDD(Test-Driven Development) 방법론