리팩터링과 테스트는 뗄 수 없는 관계이다.
또한 좋은 테스트는 개발 효율을 높인다.
4.1 자가 테스트 코드의 가치
일을 하다 보면 실제 코드를 작성하는 시간 비중은 그리 크지 않다.
대부분의 시간은 설계와 디버깅에 사용된다.
마틴 파울러도 디버깅에 많은 시간을 소비했고 테스트 코드로 구원받았다.
테스트 코드를 통해 버그를 쉽게 찾고 쉽게 고칠 수 있었기 때문에 테스트 작성 주기를 점점 짧게 가져갔다.
p.135
OOPSLA 1997에 참석하기 위해 스위스에서 애틀랜타로 향하는 비행기에서 켄트 벡은 에릭 감마와 함께 자신이 구현한 스몰토크 버전 단위 테스트 프레임워크를 자바로 포팅했다. 그 결과로 나온 것이 바로 JUnit(제이유닛)이다.
(참고로 스위스 취리히에서 애틀랜타까지 12시간 걸린다...실화냐...)
켄트 백은 테스트 코드를 추가하는 방식에서 더 나아가 기능 개발 전에 테스트를 먼저 작성하는 TDD를 창시했다.
테스트 코드의 필요성을 말하려면 끝도 없고, 이 책의 주제인 리팩터링을 하려면 테스트 코드가 반드시 필요하다는 말씀이다.
간혹 테스트가 갖춰지지 않은 코드를 리팩터링해야 할 때가 있는데, 그 때는 자가 테스트 코드부터 작성한다.
4.2 테스트할 샘플 코드
예제.
4.3 첫 번째 테스트
테스트 라이브러리는 유명한 것 중에서 편한거 사용.
자주 테스트를 실행하고 실패한 테스트가 있을 때는 리팩터링 노노.
4.4 테스트 추가하기
중요한 테스트 작성에 집중하기 위해서 필요없는 테스트는 과감히 포기해도 괜찮다. 모든 public 메소드에 대한 테스트를 작성할 필요는 없다. 예를 들면 단순한 getter, setter는 테스트가 필요없다.
테스트가 제대로 작동하는지 확인하려면 일부러 로직에 잘못된 계산식으로 변경하고 테스트를 돌린다. 테스트가 오류를 걸러내는 게 확인되면 원래 코드로 되돌리는 방식을 사용한다.
공유 픽스처 절대 금지. 기술적으로 불가능 할 때만 사용.
(픽스처 = 테스트에 필요한 데이터와 객체를 뜻함)
4.5 픽스처 수정하기
실전에서는 사용자가 값을 변경하면서 픽스처의 내용도 수정되는 경우가 흔하다. 이러한 수정 대부분은 세터에서 이뤄지는데, 세터는 보통 아주 단순하여 버그가 생길 일이 별로 없다. 하지만 좀 복잡한 동작을 수행하는 세터는 테스트가 필요하다.
setup-exercise-verify, given-when-then, arrange-act-assert 등으로 부르는 패턴을 사용할 수 있다.
4.6 경계 조건 검사하기
모든 상황이 순조롭고 사용자도 개발자 의도대로 사용하는 일명 꽃길(HAPPY PATH)만 생각하면 안된다. 경계 조건 테스트도 하는 것이 좋다.
예를 들어 배열이 비어있는 상황이나 숫자형이라면 0일 때 혹은 음수일 때를 검사해본다.
의식적으로 내가 작성한 프로그램을 파괴하는 방법을 모색해본다.
그런데 너무 빡세게 들어갈 필요는 없으며 적당히 하면 된다.
4.7 끝나지 않은 여정
여기서 다룬 테스트는 단위 테스트에 해당한다.
테스트 코드 또한 지속적인 관심과 리팩터링이 필요하다.
