TDD에 대한 몇가지 질문

• Q1 테스트 코드를 리팩터링 해야만 하나?
• Q2 테스트 코드를 리팩터링 하면 테스트를 위한 로직이 늘어나서 유지보수 부담이 증가할까?
• Q3 given/when/then을 작성하는 순서가 어떤 영향을 미치나?
• Q4 어떤 순서로 테스트 케이스를 추가하나?
• Q5 업무가 주어지면 전반적인 구현 방안이 머리가 구려지는데... 그래서 TAD를 하는데... TFD를 해야하나?

https://brunch.co.kr/@cleancode/44

클린코더스 TDD

TDD - 1

TDD의 3대 원칙

• 실패 케이스가 있을 경우에만 production 코드를 생성한다.
• 실패를 입증하기에 충분한 테스트를 작성한다.
• 어떤 테스트가 있으면 그 테스트가 통과할 만큼만 production 코드를 생성한다.

리팩토링은 선택 사항이 아니다. 필수사항이다.

원칙 & 팁

• 가장 간단하고 난이도가 낮은 부분부터 시작한다.
• 테스트 실패시 production 코드 수정은 너무 어렵게 하지 않는다. 최소한의 코드로 수정한다.
• 테스트가 많은 케이스를 수행할수록 production 코드는 범용적으로 된다.

TDD의 장점

• 디버깅에 시간을 보내는건 좋은 것이 아니다.

• 잘 작성된 테스트코드 그 자체가 문서가 된다.

• 테스트 코드를 먼저 작성하면 decoupling 된 production 코드를 갖게 된다.

• 작성자 본인이 귀찮기 때문에 먼저 작성된 테스트 코드가 복잡하게 될 코드를 작성하지 않게 된다.

• 변경을 두려워하지 않게된다.

• (중요 포인트) 테스트 코드가 있기 때문에 기능상 문제를 보장받고 리팩토링 할 수 있다.

  • 완벽한 설계에 기반해서 개발했더라도 테스트가 없다면 코드를 수정하는데 두려움이 있다.
  • 반면에 끔찍한 설계에 기반해서 개발했더라도 테스트가 있다면 코드를 수정하는데 두려움이 없다.
    실습

• 클래스 생성도 하지 않고, 테스트 코드를 먼저 만들어 실패케이스를 만든다.

• split vertical 모드로 테스트 코드와 production 코드를 함께 보면서 진행한다.

• 테스트 메소드는 한글/언더스코어를 사용해도 된다. 오직 어떤 테스트인지 나타내는데 집중한다.

TDD - 2

• 가장 빠르게 피드백을 얻을 수 있는 것을 찾아서 테스트 메소드를 작성하라.
• 그 테스트 메소드가 크게 느껴진다면 해당 메소드 코드를 주석처리하라, 그리고 이를 가장 쉬운 방식으로 쪼개보라
• extract method object를 활용하여 테스트 코드상에서 클래스가 해야하는 일들을 분리하자
• 상수는 무조건 제거대상

백명석님의 클린코더스 영상