[단위 테스트의 기술] 8장 : 유지 보수성

이 글은 단위테스트의 기술을 읽고 정리한 글입니다. 개인적으로 도움이 되었던 장을 정리하여 업로드합니다.

거짓 실패

• 프로덕션 코드의 버그가 아닌 다른 이유로 발생하는 실패를 지칭

1. 테스트가 관련이 없거나 다른 테스트와 충돌하는 경우

• 기존 기능 / 요구사항에 맞추어 작성했던 테스트 코드(현재는 유효하지 않은.)
• 이런 경우는 기존 테스트를 삭제한다.

2. 프로덕션 코드의 API 변경

• 실제 테스트 대상, 테스트에 도움을 주는 대상의 생성자 파라미터 추가 / 삭제
• 생성자 파라미터 자료형 변경
• 함수 시그니처 변경
• 이런 경우에는, 테스트할 코드의 생성 과정을 다음과 같은 방법을 이용하여 분리 + 추상화를 한다.
  • 팩토리 메서드
  • Object Mother
  • Test fixture

3. 다른 테스트가 변경되었을 경우

1. 순서가 정해진 테스트
   1. 테스트 간에 어떠한 테스트가 선행되어야 하는 테스트가 있다면, 다음과 같이 리팩터링한다
      1. 객체를 생성하는 헬퍼 함수를 만든다.
      2. beforeEach()등으로 테스트마다 필요한 객체를 생성한다.

유지 보수성을 높이는 테스트 작성 방법

1. private / protected 메서드 테스트하지 않기

• private / protected는 애초에 접근을 제한할 용도로 사용한다.
  • 따라서 세부구현이 바뀌더라도, 외부에서 보이는 동작은 바뀌지 않을 것이므로
  • private 메소드를 사용하는 public 메소드에서 간접적으로 테스트 하는 것이 더 효율적이다.

2. 테스트에서도 DRY 원칙 고수

• 헬퍼 함수 등을 통하여 DRY 원칙을 지킨다.

3. 초기화 함수를 사용하지 않기

• beforeEach()함수를 사용하여 초기화를 하는 것은, 세밀한 조정이 들어가기 힘듦으로 테스트마다 헬퍼 함수 등을 사용하여 객체를 생성하자.
• 초기화 함수에는 현재 테스트 클래스의 모든 테스트 케이스에 적용되는 코드만 포함한다.

4. 매개변수화된 테스트로 중복 코드 제거

• 테스트 케이스마다 input 데이터를 달리하고 싶으면, 각자 다른 테스트 케이스를 작성하는 것 보다 parameterized Test를 진행한다.

과잉 명세된 테스트

1. 목을 사용한 내부 동작 과잉 명세

• verify()를 이용하여, 내부 동작이 실행되었는지에 대한 테스트보다, 종료점(함수 값 리턴, 객체 상태 변경, 서드 파티 호출)에 대한 테스트를 진행해야 한다.

2. 결과와 순서를 지나치게 세밀하게 검증

• 테스트 결과 중, 예를 들어 배열과 같은 리턴값이 있다면 배열의 특정 인덱스를 사용하여 테스트 결과를 확인 하는 것은,
  • 배열의 길이가 변경될 때
  • 결과의 순서가 변경될 때
• 등의 상황에서 문제가 될 수 있다.