10장 테스트 코드와 유지보수

테스트 코드와 유지보수

• 테스트 코드는 그 자체로 코드이기 때문에 제품 코드와 동일하게 유지보수 대상이 된다.
• 이런 악순환이 발생하지 않으려면 테스트 코드 자체의 유지 보수성이 좋아야 한다.
• 좋은 테스트 코드를 만들려면 몇가지 주의해야 할 사항이 있다.

변수나 필드를 사욜해서 기댓값 표현하지 않기

• 객체를 생성할 때 사용한 값이 무엇인지 알아보기 위해 필드와 변수를 참조하지 않아도 된다. 단언할 때 사용한 값이 무엇인지 알기 위해 필드와 변수를 오갈 필요도 없다.

두 개 이상을 검증하지 않기

• 한 테스트 메서드에서 서로 다른 내용을 검증한다면 각 검증 대상을 별도로 분리해서 테스트의 집중도를 높일 수 있다.
• 물론 테스트 메서드가 반드시 한 가지만 검증해야 하는 것은 아니지만, 검증 대상이 명확하게 구분된다면 테스트 메서드도 구분하는 것이 유지보수에 유리하다.

정확하게 일치하는 값으로 모의 객체 설정하지 않기

• 모의 객체는 가능한 범용적인 값을 사용해서 기술해야 한다.

과도하게 구현검증하지 않기

• 테스트 코드를 작성할 때 주의할 점은 테스트 대상의 내부 구현을 검증하는 것이다.
• 내부 구현은 언제든지 바뀔 수 있기 때문에 테스트 코드는 내부 구현보다 실행 결과를 검증해야 한다.

셋업을 이용해서 중복된 상황을 설정하지 않기

• 각 테스트 메서드는 별도 프로그램으로서 검증 내용을 스스로 잘 설명할 수 있어야 한다. 그러기 위해서는 상황 구성 코드가 테스트 메서드 안에 위치해야 한다.
• 테스트 메서드는 자체적으로 검증하는 내용을 완전히 기술하고 있어야 테스트 코드를 유지보수하는 노력을 줄일 수 있다.

통합 테스트에서 데이터 공유 주의하기

• 통합 테스트 코드를 만들 때는 다음의 두 가지로 초기화 데이터를 나눠서 생각해야 한다.
  • 모든 테스트가 같은 값을 사용하는 데이터: 예) 코드값 데이터
  • 테스트 메서드에서만 필요한 데이터: 예) 중복 ID 검사를 위한 회원 데이터

통합 테스트의 상황 설정을 위한 보조 클래스 사용하기

• 테스트 메서드에서 직접 상황을 구성하면서 코드 중복을 없애는 방법이 있는데 그것은 바로 상황 설정을 위한 보조 클래스를 사용하는 거싱다.

실행 시점이 다르다고 실패하지 않기

• 시점을 제어하는 또 다른 방법은 별도의 시간 클래스를 작성하는 것이다.

랜덤하게 실패하지 않기

• 실행 시점에 따라 테스트가 실패하는 또 다른 예는 랜덤 값을 사용하는 것이다.
• 직접 랜덤 값을 생성하지 말고 생성자를 통해 값을 받도록 수정하면 테스트가 가능해진다.
• 랜덤 값 생성을 다른 객체에 위임하게 바꿔도 된다.

필요하지 않은 값은 설정하지 않기

• 테스트에 필요한 값만 설정하면 필요하지 않은 값을 설정하느라 고민할 필요가 없다. 또한, 테스트 코드가 짧아져서 한눈에 내용을 파악할 수 있다.
• 테스트를 위한 객체 생성 클래스를 따로 만들면 이런 복잡함을 줄일 수 있다.

조건부로 검증하지 않기

• 테스트는 성공하거나 실패해야 한다.

더 이상 쓸모 없는 테스트 코드

• 테스트 커버리지를 높이기 위한 목적으로 작성한 테스트 코드도 유지할 필요가 없다.