4. 테스트 구축하기

4. 테스트 구축하기

• 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 있어야한다.

4.1 자가 테스트 코드의 가치

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

4.3 첫 번째 테스트

• 실패해야 할 상황에서는 반드시 실패하게 만들자
• 자주 테스트하자. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자

4.4 테스트 추가하기

• 테스트는 위험 요인을 중심으로 작성해야 한다
• 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다.
• 테스트 관련 버그중 가장 지저분한 유형: 테스트끼리 상호작용하게 하는 공유 픽스쳐
  • 개별 테스트를 실행할 때마다 픽스처를 새로 만들면 모든 테스트를 독립적으로 구성할 수 있다.

4.5 픽스처 수정하기

• 일반적으로 it 구문 하나당 검증도 하나씩만 하는 게 좋다.
  • 앞쪽 검증을 통과하지 못하면 나머지 검증은 실행해보지 못하고 테스트가 실패하게 되는데, 그러면 실패 원인을 파악하는 데 유용한 정보를 놓치기 쉽기 때문이다.

4.6 경계 조건 검사하기

• happy path를 벗어나는 경계 지점에서 문제가 생기면 어떤일이 벌어지는지 확인하는 테스트도 함께 작성하면 좋다.
• 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.
• 테스트가 모든 버그를 걸러주지는 못할지라도, 안심하고 리팩터링할 수 있는 보호막은 되어준다.

4.7 끝나지 않은 여정

• 버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하자.