테스트 주도 개발

  TDD의 원조, 시작이라 할 수 있는 바로 그 책이다. 켄트 벡 특유의 말장난을 치는데 영미권 사람이 아니라 역자주의 말을 보고 피식하게 되는건 조금 아쉽다! (나도 자연스럽게 웃고싶다) 어렵지 않은 예제(화폐 예제)로 하나씩 기능을 만들어 나가고 리팩토링 하는 과정을 보여준다. 그 과정들을 요약하자면 아래와 같다.

1. 테스트 작성.

2. 컴파일되게 하기.

3. 실패하는지 확인하기 위해 실행.

4. 실행하게 만듦.

5. 중복 제거.

  한 문장으로 요약하면 "빨간막대 - 초록막대 - 리팩토링"이라고 할 수 있다. (빨간 막대와 초록막대는 JUnit을 돌릴 때, 실패하면 빨간색, 성공하면 초록색으로 나타나기 때문이다) 중복되는 코드를 공통 메서드로 뺀다던지 추상클래스로 뽑아 내는 등 TDD를 하면서 효과적으로 코드를 수정해 나간다. 일단 컴파일이 되게 하기 위해, 또 일단 초록막대를 보기 위해 말그대로 하드코딩을 하기도 한다. 어떻게 보면 비효율 적으로 보이지만 그 잠깐의 시간을 투자해서 보다 더 큰 것을 얻게 해준다. 호흡과 리듬이라는 부분이다. 빨간막대를 보면 빠르게 초록막대를 보고 빠르게 리팩토링을 하는 것이다. 

  이 책을 읽기 전에도 테스트코드가 없으면 기존 코드를 수정하기 무서웠는데, 지금은 더욱 그렇게 되었다. 테스트코드는 리팩토링을 함에 있어서 더 과감해질 수 있게 하고, 더 안심을 시켜준다는 면에서 물고기에게 물같은 존재 같다. 단위테스트를 함으로써 불필요하게 전체 통합테스트 횟수를 줄여주고 빠르게 나의 코드를 검증해 준다. 

  TDD가 전체 개발 시간을 줄여 준다는 것에는 이제 구구절절히 설명하지 않아도 많은 사람들이 동의하는 것 같다. 처음에 단위테스트를 작성하느라 시간이 소요 되겠지만 시간이 가고 개발 막바지가 되고, 또 유지보수를 하게 되면 단위테스트는 더 빛을 내기 시작한다. 남이 만든 기존 시스템을 빠르고 자신있게 수정할 수 있는 사람이 얼마나 되겠는가? 테스트 코드가 있다면 큰 도움이 된다. 

  토비의 스프링에서 봤는지 어디서 봤는지 정확히 기억나지 않지만 대충 이런 내용이었다. "언어를 배우기 전에 (다른 시스템을 이해하기 전에던가?) 단위테스트부터 돌려본다"라고. 그 말에 백번 동의 하는 것이 나도 지금 스칼라로 되어 있는 기존 시스템에 새로운 기능을 추가해야 하는 상황이 왔는데, 이미 짜여진 테스트 코드를 돌려보며 분석중에 있기 때문이다. 이처럼 테스트 코드는 여러모로 장점이 많다. TDD와 단위테스트, 테스트 코드 등을 구분없이 사용하고 있는데 (아직 정확히 구분할 줄 모르기도 하거니와) TDD를 한다면 당연히 단위테스트들은 있을 것이기 때문이다. 

  p.s. 요새 JS도 간단히 유지보수 하고 있는데 JS에서는 TDD를 어떻게 할까? 그게 아니더라도 단위테스트는 어떻게 돌리지?

 

  테스트 주도 개발, 인사이트(켄트 벡)