티스토리 뷰

Old

클린 코더스 강의 7. TDD 정리

Voyager Woo 2014. 8. 6. 19:26
반응형

클린 코더스 강의 7. TDD 정리




TDD 실습

1. TDD 의 세가지 법칙

- Failing test code 가 있을 때만 production code를 작성해라.

- 실패를 나타낼 수 있는 충분한(적당한) 테스트만 작성해라.

- 실패하는 테스트가 있으면 성공하는 만큼의 production code를 작성하라.


2. TDD 절차

A. 실패 테스트 코드 작성 (RED)

B. 테스트 코드를 패스하는 코드 작성 (GREEN)

C. 리펙토링(중복제거) (BLUE)

D. A, B, C 반복

E. 실패를 나타낼 충분한 코드를 작성했다면 종료



3. 원칙 & 팁

- 가장 간단하고 흥미롭고 수준이하의(degenerate) 쉬운거 부터 제일 먼저한다.

- Little golf game : 최소한의 프로덕션 코드로 테스트를 통과해라.

- 테스트가 점점 구체화될 수록, 프로덕션 코드는 점점 더 범용적(generic)이 된다.


4. TDD의 이점

- 디버깅 타임을 줄일 수 있다.

우리는 디버깅 챔피언이 목적이 아니다. 디버깅에 시간을 쏟는 거 보다 코드가 제대로 동작하는데 시간을 쏟는 것이 중요하다. 서버 재기동(restart)시간만 고려해도 유닛 테스트로 테스트하는 것이 디버깅 보다 훨씬 빠르며, 이렇게 되면 더 빨리 제대로 동작하는 코드를 작성할 수 있다.

- TDD의 세가지 법칙을 잘 준수했을 때 테스트 코드는 좋은 설계 문서가 된다.

- Decoupling 의존성 제거

어느날 보면 테스트가 어려워진 프로덕션 코드들이 생긴다. 테스트가 어려운 이유는 의존성이 높기 때문이다. 만약 기능을 구현하는 프로덕션 코드 작성 전에 그 기능을 사용하는 클라이언트 코드를 먼저 작성했다면 프로덕션 코드는 어떻게든 사용하기 쉽게 만들었을 것이다. 예를 들어 파라미터가 15개가 넘는 코드는 만들지 않았을 것이다. 

이처럼 테스트 코드를 먼저 작성했으면 그리고 세가지 규칙을 잘 지킨다면 의존성이 낮고 테스트하기 용이한 프로덕션 코드를 만들었을 것이다.

- 테스트 코드가 있다면 용기있게 코드를 변경할 수 있다.

개발자가 리펙토링을 두려워 하면 코드는 썩는다. 테스트 코드는 회귀 테스트(Regression Test)를 제공하여 개발자들이 기존 코드를 쉽게 변경할 수 있게 하기 때문에 코드를 깨끗하게 하고, 썩는 것을 방지한다. (레거시 코드는 예외)

또한 아무리 완벽하게 설계하여 개발하였다고 하더라도 테스트가 없다면 코드를 깨끗하게 하는데 두려움이 있다. 따라서 깨끗했던 코드는 점점 더러워질 것이다.

반대로 이상하게 설계를 했다고 하더라도  테스트 코드가 있다면 점진적으로 점점 좋아질 것이다.

- TDD 의 세가지 규칙을 준수했을 때 개발자들은 낙하산 같은 안전장치를 얻게된다.

- 개발 이후 테스트 (TAD, Test After Development)는 신뢰할 수 없다. 왜냐하면 이미 수작업으로 코드가 동작함을 확인했고, 동작하는 것만을 확인 하는 테스트를 작성할 수 있기 때문에 구멍이 있을 가능성이 높다.

- 이미 동작함을 확인했으므로 낭비적으로 느껴지며, 그렇기 때문에 꼭 필요한 테스트(short cut)만 작성하게 된다. 

반응형
댓글
댓글쓰기 폼