TDD란?

• “프로그램을 작성하기 전에 테스트를 먼저 하라” - 켄트 백(TDD 창시자) -
• TDD란 실제 업무 코드를 작성하기 전에 테스트 코드를 먼저 만드는 것.
• 테스트 코드를 작성해서 프로그램이 잘못되었음을 증명하고, 잘못된 부분을 수정해서 목표에 부합하는 코드를 만드는 개발 방법론.
• 최대한 빨리 실패하고 자주 실패를 경험하는 방식.

TDD를 사용하는 이유?

• “테스트 커버리지가 높아진다.”
  • 개발 시 테스트 케이스를 작성하는 것이 선행되기 때문에 개발을 한 후에 테스트 코드 작성을 잊거나 생략하는 것을 방지할 수 있다.
• “오버 엔지니어링 방지.”
  • 시스템에 정말 필요한 코드만 작성할 수 있다. 미래의 필요할 것 같은 구현을 지레짐작하여 불필요한 코드를 작성하는 것을 방지할 수 있다.
• “설계에 대한 피드백이 빠르다”
  • 개발 후 테스트 단계에서 설계의 문제점을 파악했을 때는 이미 많이 늦어버린 상태가 된다. 설계 후 바로 테스트 코드를 작성하면 설계의 문제점을 빠르게 파악할 수 있어 수정 및 피드백이 용이하다.

TDD의 진행방식

• 단위테스트 구현 후 기능 구현을 수행.

  • 질문(Ask) : 작성하고자하는 메소드나 기능이 무엇인지 선별하고 작성 완료 조건을 정해서 실패하는 테스트 케이스를 작성하는 과정. 모든 케이스를 예상해서 내가 짠 코드가 올바르지 않음을 증명해야함.
  • 응답(Respond): 테스트 케이스를 통과하는 코드를 작성하는 과정. todo list를 작성하며 진행해 나감.
  • 정제(Refine) : todo 목록을 지우면서 리팩토링이 필요한지 확인.(소스의 가독성은 적절한지? 중복된 코드가 없는지? 이름이 잘못 부여된 메소드가 변수명은 없는지? 구조개선이 필요하지는 않는지?)

  —> TDD를 이용한 개발은 ‘질문 → 응답 → 정제’ 의 세 단계가 반복적으로 이루어진다.

TDD를 실패하는 이유?

• 코드가 이루고자 하는 가치나 기능을 테스트하기보다는 그 기능을 어떻게 구현하고 있는지를 테스트한다.

• 결국 테스트 케이스들이 구현체와 결합도가 높아진다.

• 구현체들을 리팩토링하면 결합되어있는 테스트 케이스들이 모두 깨져버린다.

  (1) 구현체에 대해 작성한 테스트 코드

  

  (2) 구현체를 리팩토링

  (3) 테스트들이 모두 깨지게 됨!

  

(4) 결론 : 리팩토링 후에도 테스트는 영향을 받지않도록 구현체가 아닌 인터페이스를 기준으로 테스트는 작성되어야 함