8장 테스트 가능한 설계

테스트가 어려운 코드

하드 코딩된 경로

• 하드 코딩된 경로뿐만 아니라 하드 코딩된 IP주소, 포트번호도 테스트를 어렵게 만든다.

의존 객체를 직접 생성

• 테스트를 어렵게 만드는 도 다른 요인은 의존 대상을 직접 생성하고 있다

정적 메서드 사용

• 정적 메서드를 사용해도 테스트가 어려워질 수 있다.

실행 시점에 따라 달라지는 결과

• 테스트를 실행하는 시점에 다라 테스트 결과가 달라진다면 그 테스트는 믿을 수 없게 된다.

역할이 섞여 있는 코드

• 대역을 알맞게 설정해야만 포인트 계산도 가능해진다.

그 외 테스트가 어려운 코드

• 이 외에 테스트 대상이 다음과 같다면 테스트가 여려울 수 있다.
  1. 메서드 중간에 소켓 통신 코드가 포함되어 있다.
  2. 콘솔에서 입력을 받거나 결과를 콘솔에 출력한다.
  3. 테스트 대상이 사용하는 의존 대상 클래스나 메서드가 final이다. 이 경우 대역으로 대체가 어려울 수 있다.
  4. 테스트 대상의 소스를 소유하고 있지 않아 수정이 어렵다.

테스트 가능한 설계

• 사오하엥 따라 알맞은 방법을 적용하면 의존 코드를 교체할 수 있게 만들 수 있다.

하드 코딩된 상수를 생성자나 메서드 파라미터로 받기

• 하드 코딩된 상수 때문에 테스트가 힘들다면 해당 상수를 교체할 수 있는 기능을 추가하면 된다.

의존 대상을 주입받기

• 의존 대상은 주입 받을 수 있는 수단을 제공해서 교체할 수 있도록 한다.

테스트하고 싶은 코드를 분리하기

• 이렇게 기능의 일부만 테스트하고 싶다면 해당 코드를 별도 기능으로 분리해서 테스트를 진행할 수 있다.

시간이나 임의 값 생성 기능분리하기

• 테스트 대상이 사용하는 시간이나 임의 값을 제공하는 기능을 별도로 분리해서 테스트 가능성을 높일 수 있다.
• 임의의 값도 비슷하다. 임의 값을 제공하는 라이브러리를 직접 사용하지 말고 별도로 분리한 타입을 사용해서 대역으로 처리할 수 있어야 테스트 가능하게 만들 수 있다.

외부 라이브러리는 작접 사용하지 말고 감사서 사용하기

• 대역으로 대체하기 어려운 외부 라이브러리가 있다면 외부 라이브러리를 직접 사용하지 말고 외부 라이브러리와 연동하기 위한 타입을 따로 만든다.