백명석 님의 클린 코더스 강의를 듣고 요약정리한 글입니다. 문제가 있을 경우 삭제 조치하도록 하겠습니다.
1. The Three Laws of TDD
- 실패하는 테스트가 있을 때만, 프로덕션 코드를 작성해야 한다.
- 실패를 나타내는 데 충분한 정도의 테스트만 작성해야 한다. (테스트 or 프로덕션 한 곳에서 너무 오래 머물지 않기)
- 실패하는 테스트가 있다면 성공할 수 있도록 최소한만 작성한다.
위 원칙을 어기면, 사이클을 돌기 어렵다. (stocking이라고 하는데, 옴짝달싹하지 못하는 상태)
2. TDD 절차
실패하는 테스트를 작성하는 것이 레드, 테스트를 통과하도록 최소한 코드를 작성하는 것이 그린, 리팩터링 하는 것이 블루 단계라고 한다. 리팩터링 할 때는 중복이 없어야 하며, 구조와 설계를 개선해야 한다. 위 단계를 더 이상 테스트를 추가할 수 없을 때까지 반복한다. TDD에서 리팩토링은 필수이다.
3. 원칙과 팁
- 일단 간단하고, 해보기 쉬운 것을 먼저 시도해야 한다. (most simple / degenerate(수준 이하의) test case first)
- 실패하는 테스트를 통과하기 위해서는 최소한의 코드를 작성해야 한다. (little golf game)
- 테스트가 구체화될 수록 프로덕션은 코드는 점점 범용적이게 된다. (모든 케이스를 수용한다는 의미)
4. TDD의 이점
- 디버깅 시간을 줄일 수 있다. 디버깅은 알아야 하는 스킬이지만, 이것에 시간을 많이 보내기보단 코드가 동작하도록 시간을 사용하는 것이 더 필요하다. (TDD는 디버깅 시간을 1/10으로 줄일 수 있다. 1/2만 줄여도 의미가 있다.)
- TDD의 3가지 법칙을 잘 따르면 설계 문서를 얻게된다. (test는 low level design document)
- TDD로 구현하면 보다 decouple된 시스템을 갖게 된다. (테스트 코드에서 코드 라인을 접근하기 위한 유일한 방법은 테스트하려는 코드를 다른 코드들과 decouple 시키는 것)
- 테스트가 있으면 변경을 무서워하지 않게 된다. 테스트는 코드를 깨끗하게 하고, 썩는 것을 방지한다.
- 3가지 규칙을 준수했을 때 낙하산을 가지고 있는 것과 같은 믿음을 테스트에 가질 수 있게 된다. 이미 작성된 코드에서 테스트를 작성하면 (TAD라고 함) 지루하고, 신뢰가 떨어지고, short cut을 취하게 된다.
5. 실습 준비
- tyrant 설치
- inteliJ Ultimate Edition 설치
- msbaek/tdd-practice 클론