[리팩터링] 4장. 테스트 구축하기

자가 테스트 코드의 가치

• 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자.
• 디버깅 시간이 크게 줄어든다.
• 리팩터링 하고 싶다면 테스트를 반드시 작성하자.
• 테스트의 용이성을 아키텍처 평가 기준으로 활용하는 사례도 많다.

TDD : Test-Driven Development. 테스트 주도 개발

• 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 기능을 추가해야 할 때 테스트부터 작성하자.
• 구현보다 인터페이스에 집중하게 된다.
• 코딩이 완료되는 시점을 정확하게 판단 할 수 있다. 테스트를 모두 통과한 시점 == 코드를 완성한 시점

테스트 코드 작성 요령

• 어떤 코드를 테스트 할 것인가?
  • 외부에서 들어온 입력 객체(JSON으로 인코딩된 요청 등)
  • 요구사항이 명확할 때
  • 비지니스 로직
  • 협업시 명세서(문서) 역할
  • 설계에 대한 고민이 필요할 때
• 어떤 코드를 테스트 안할 것인가?
  • 단순히 필드를 읽고 쓰기만 하는 접근자
  • 같은 코드베이스의 로직에서 이미 테스트 코드가 있는 경우
  • view 에 관련된 코드 (선택) → 그냥 눈으로 확인하는게 나은 것 같음
• 실패해야 할 상황에서는 반드시 실패하게 만들자. 일시적으로 코드에 오류를 주입한다던지..
• 엣지케이스도 테스트 작성하자. ( 값이 비어있음, zero, 음수 등 )

테스트 프레임워크 사용 예시

/* 여러 테스트케이스들을 그룹화 */
describe(description, () => { 	
	/* beforeEach 안쓰고 바로 픽스처를 최상단에 쓰면 테스트 순서에 의해 값이 변경 될 수 있음 */
		
	/* 픽스처(초기 준비 작업 중 공통되는 부분) 작성 */
	beforeEach(() => { ... });
	
	/* 개별 테스트 케이스 */
	it('테케1', () => { ... }); // it 하나당 한가지만 검증하자
	it('테케2', () => { ... });
});

테스트의 품질 향상

• 한 번에 완벽한 테스트를 갖추기는 어려우므로 테스트 스위트를 지속해서 보강한다. 기존 테스트가 명확한지, 이해하기 쉽게 리팩터링할 수 없는지, 제대로 검사하는지 등을 확인한다.
• 버그를 발견하는 즉시 발견한 버그를 명확히 잡아내는 단위 테스트부터 작성하는 습관을 들이자.
• 테스트 커버리지 분석은 코드에서 테스트하지 않는 영역을 찾는 데만 도움될 뿐, 테스트 스위트의 품질과는 크게 상관없다.