Test Driven Development

테스트 주도 개발이 주는 혜택은 무엇일까?

테스트 주도 개발

• TDD를 처음 들었을 때는 충격이었다.
• 단위 테스트를 먼저 만들라니?
• 켄트 백이 TDD를 어떻게 보여주었는지 대한 예시를 보곤 충격먹었다.
• 코드 실행 주기가 30초였다. 본인은 다 만들고 한번 하니 1시간 남짓이었다.
  • 한참 코딩 > 컴파일 (여기도 시간) > 오류 (시간 더 잡아먹음)

TDD의 세가지 법칙

1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
2. 컴파일이 안되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

• 이렇게 하면 반복 주기를 30초를 유지한다.
• 제품 코드와 테스트 코드가 상호 보완되면서 자라난다.

수많은 혜택

확신

• 테스트가 제품 코드의 90% 이상을 커버한다면 어떨까?
• 제품이 준비되었다고 거의 확신할 수 있을 것이다.

결함 주입 비율

• 결함이 감소하는 비율이 높아진다.
• 이는 여러 보고서와 연구에서 증명되었다.

용기

• 뭔가를 망가트리더라도 테스트 코드가 잡아줄 거라는 생각에 리팩토링 작업에 용기를 얻는다.
• 이는 제품이 썩어가는 것을 방지할 수 있다.

문서화

• 코드를 사용하는 방법을 알려면 코드를 읽어야 한다.
• 단위테스트를 보면 곧 예제를 알 수 있다.
• 곧 문서가 되는 것이라 생각할 수 있다.

설계

• 테스트 코드를 만들려면 코드의 의존관계를 고립시켜야 한다.
• 이는 결합도를 낮추고 응집도를 높이는 효과가 있다.
• 곧 좋은 설계로 나아간다.
• 그렇기에 테스트 코드를 먼저만들어야 한다.

프로다운 선택

• 결론 적으로 TDD는 프로다운 선택이다.

TDD와 관련없는 사실

• 그럼에도 TDD는 종교나 마법이 아니다.
• 테스트가 있어도 형편없는 코드가 나오기도 한다.
• 같은 맥락에서 3가지 법칙을 무조건 따르는 일이 실용적이지 않고 적절하지 않을 때도 있다.
• 모든 엔지니어링은 상황에 맞는 방법을 쓰는 것이 최고다. 이를 잊지는 말자.
  • 하지만 대부분은 TDD사용이 옳다.

Reference

• The Clean Coder