[xUnit 테스트 패턴] 05장 - 테스트 자동화의 원칙
05장 - 테스트 자동화의 원칙
원칙
원칙 : 테스트를 먼저 작성하라
- 단위테스트는 디버깅에 드는 노력을 충분히 보상한다.
- 테스트를 자동화하는 데 드는 노력을 충분히 벌충 해 준다.
- 코드를 테스트하기 쉽게 설계하게 된다.
원칙 : 테스트하기 쉽게 설계하라
- 테스트 용이성을 고려하지 않고 작업한 후에 자동 테스트를 작성하기란 불가능할 수 있다.
원칙 : 정문을 먼저 사용하라
- public 인터페이스로 객체를 테스트하고 상태 검증으로 제대로 동작헀는지 확인해야 한다.
- 테스트를 검증하기 위해 뒷문 조작(Back Door Manipulation)을 하면 너무 결합된 소프트웨어가 돼 자주 테스트를 유지 보수 해줘야 한다.
원칙 : 의도를 드러내라
- 테스트에 코드가 너무 많거나(10줄 이상..) 테스트 내 조건문 로직이 들어있다면 대부분이 애매한 테스트 이다.
- 의도를 드러내는 테스트
- 의도가 드러나는 이름의 테스트 유틸리티 메소드로 테스트 픽스처를 설치하거나 기대 결과 값이 나왔는지를 검증
- 테스트 메소드에서 테스트 픽스처가 각 테스트의 기대 결과 값에 어떤 영향을 미치는지, 어떤 값을 입력하면 어떤 값이 출력되는지 바로 알아볼 수 있어야 함
- 풍부한 테스트 유틸리티 메소드 라이브러리 역시 테스트를 작성하기 쉽게 해준다.
원칙 : SUT를 고치지 마라
- 테스트 훅을 넣는다던가, 테스트용 하위클래스에서 동작을 오버라이딩한다던가, 의존 컴포넌트(Depended-On Component, DOC)를 테스트 대역으로 바꾼다던가 하는 식의 SUT를 변경하는 것은 위험하다.
- 테스트하는 코드가 더 이상 제품에 들어가는 코드가 아니게 될 수 있다.
원칙 : 테스트를 독립적으로 유지하라
- 서로 반응하는 테스트는 보통 단체로 실패한다.
- 자신만의 신선한 픽스처를 설치한다.
- 공유 픽스처를 사용하는 테스트보다 훨씬 독립적이다.
- 단위 테스트 실패가 결함 국소화를 제공해 실패의 원인이 무엇인지 정확히 집어 낸다.
원칙 : SUT를 격리하라
- 소프트웨어의 테스트하지 않는 부분과는 최대한 격리시켜야 한다.
- 따로 테스트 할 수 있고, 테스트를 서로 독립적으로 유지할 수 있다.
- 견고한 테스트를 만드는데 좋다.
원칙 : 겹치는 테스트를 최소화하라
- 특정 기능에 의존하는 테스트의 수를 최대한 작게 만들어야 한다.
- 같은 기능을 검증하는 테스트는 실패 할 때 다 같이 실패한다.
- SUT에서 기능이 변경될 경우 모든 테스트를 전부 유지 보수해야줘야 한다.
- 테스트 조건은 딱 하나의 테스트로 다뤄줘야 한다.
원칙 : 테스트할 수 없는 코드를 최소화하라
- 테스트하기 불가능한 코드
- 테스트할 수 없는 코드가 있다면 기존 기능을 변경하거나 새로운 기능을 추가하기 위험 해 진다.
원칙 : 테스트 로직을 제품 코드에 넣지 마라
- 테스트는 시스템의 동작을 검증하는 행위다.
- 제품코드에는 테스트 조건문과 로직이 없어야 한다.
원칙 : 테스트별로 하나의 조건만 검증하라
- 스크립트 기반 테스트는 한 가지 테스트 조건만 검증해야 한다.
- 각 테스트를 4단계로 실행하게 설계한다.
- 1단계 : 픽스처 설치
- 2단계 : SUT 실행
- 3단계 : 결과 검증
- 4단계 : 픽스처 해체
- 테스트에는 하나의 단언문(Assertion)만 있으면 좋다
원칙 : 따로 테스트하라
- 하나의 테스트 메소드에서 여러 관심을 테스트하는 데 따른 문제
- 여러 관심 중 하나라도 변경되면 테스트 메소드가 깨진다.
- 어떤 관심이 실패를 유발하는지 분명하지 않다.
- 결함 국소화가 잘 안 돼 있으므로 수동 디버깅을 해야 한다.
원칙 : 효과와 책임을 적당하게 맞춰라
- 테스트 작성, 관리에 필요한 도구가 기능 구현에 필요한 도구보다 더 어려워서는 안 된다.