테스트 주도 개발이 주는 혜택은 무엇일까?
테스트 주도 개발
- TDD를 처음 들었을 때는 충격이었다.
- 단위 테스트를 먼저 만들라니?
- 켄트 백이 TDD를 어떻게 보여주었는지 대한 예시를 보곤 충격먹었다.
- 코드 실행 주기가 30초였다. 본인은 다 만들고 한번 하니 1시간 남짓이었다.
- 한참 코딩 > 컴파일 (여기도 시간) > 오류 (시간 더 잡아먹음)
TDD의 세가지 법칙
- 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
- 컴파일이 안되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
- 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.
- 이렇게 하면 반복 주기를 30초를 유지한다.
- 제품 코드와 테스트 코드가 상호 보완되면서 자라난다.
수많은 혜택
확신
- 테스트가 제품 코드의 90% 이상을 커버한다면 어떨까?
- 제품이 준비되었다고 거의 확신할 수 있을 것이다.
결함 주입 비율
- 결함이 감소하는 비율이 높아진다.
- 이는 여러 보고서와 연구에서 증명되었다.
용기
- 뭔가를 망가트리더라도 테스트 코드가 잡아줄 거라는 생각에 리팩토링 작업에 용기를 얻는다.
- 이는 제품이 썩어가는 것을 방지할 수 있다.
문서화
- 코드를 사용하는 방법을 알려면 코드를 읽어야 한다.
- 단위테스트를 보면 곧 예제를 알 수 있다.
- 곧 문서가 되는 것이라 생각할 수 있다.
설계
- 테스트 코드를 만들려면 코드의 의존관계를 고립시켜야 한다.
- 이는 결합도를 낮추고 응집도를 높이는 효과가 있다.
- 곧 좋은 설계로 나아간다.
- 그렇기에 테스트 코드를 먼저만들어야 한다.
프로다운 선택
TDD와 관련없는 사실
- 그럼에도 TDD는 종교나 마법이 아니다.
- 테스트가 있어도 형편없는 코드가 나오기도 한다.
- 같은 맥락에서 3가지 법칙을 무조건 따르는 일이 실용적이지 않고 적절하지 않을 때도 있다.
- 모든 엔지니어링은 상황에 맞는 방법을 쓰는 것이 최고다. 이를 잊지는 말자.
Reference