04 테스트 구축하기

리팩터링을 재대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 뒷받침돼야 한다.

1. 자가 테스트 코드의 가치

• 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자.
• 테스트 코드 자체뿐 아니라 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 된다.
• 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여준다.
• 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다.
• 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게된다.
• 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 게다가 코딩이 완료되는 시점을 정확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다.
• 리팩터링에는 테스트가 필요하다. 그러니 리팩터링을하고 싶다면 테스트를 반드시 작성해야 한다.

2. 테스트할 샘플 코드

3. 첫 번째 테스트

• 실패해야 할 상황에서는 반드시 실패하게 만들자.
• 기존 테스트를 모두 통과 했을 때, 일시적으로 오류 코드를 주입해서 테스트가 실패하는 모습을 최소한 한번씩 직접 확인해본다.
• 자주 테스트 하라. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자.

4. 테스트 추가하기

• 테스트는 위험요인을 중심으로 작성해야 한다.
• 테스트의 목적은 어디까지나 현재 혹은 향후에 발생하는 버그를 찾는 데 있다.
• 따라서 단순히 필드를 읽고 쓰기만 하는 접근자는 테스트할 필요가 없다.
• 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다.

5. 픽스처 수정하기

• 흔히 테스트를 설정-실행-검증(setup-exercise-verify), 조건-발생-결과(given-when-them), 준비-수행-단언(arrange-act-assert) 등으로 부른다.

6. 경계 조건 검사하기

• 범위를 벗어나는 경계 지점에서 문제가 생기면 어떤 일이 벌어지는지 확인하는 테스트도 함께 작성하면 좋다.
• 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.
• 어차피 모든 버그를 잡아낼 수 없다고 생각하여 테스트를 작성하지 않는다면 대다수의 버그를 잡을 수 있는 기회를 날리는 셈이다.
• 테스트를 너무 많이 작성하다 보면 오히려 의욕이 떨어져 나중에는 하나도 작성하지 않게 될 위험도 있다. 따라서 위험한 부분에 집중하는 게 좋다.

7. 끝나지 않은 여정

• 테스트도 굉장히 중요한 주제다. 리팩터링에 반드시 필요한 토대일 뿐만 아니라, 그자체로도 프로그래밍에 중요한 역할을 한다.
• 기능을 새로 추가할 때마다 테스트도 추가하는 것은 물론, 기존 테스트도 다시 살펴본다.
• 버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하자.
• 테스트 코드의 목적은 믿음을 갖게 해주는 것이다. 리팩터링 후 테스트 결과가 모두 초록색인 것만 보고도 리팩터링 과정에서 생겨난 버그가 하나도 없다고 확신할 수 있다면 충분히 좋은 테스트 스위트라 할 수 있다.

참고
리팩터링 2판