본문 바로가기

UnitTest

[Test] 테스트 가능 설계를 위한 지침 (Effective Unit Testing)

내용이 좋아서 정리..


1. 복잡한 private 메서드를 피한다. 

private 메서드 사용법이 명확하지 않고 전용 테스트까지 만들고 싶은 마음이 생긴다면

오히려 코드를 리팩토링하라는 신호로 생각하자. private 메서드는 직접 테스트하지 말아야한다.


2. final 메서드를 피한다. 

실질적으로 메서드를 final로 선언해야 할 합리적인 사유는 실행 도중에 외부 클래스를 로딩하거나

여러분이 옆의 동료를 믿지 못할 때뿐이다. (ㅋㅋ)

final이 테스트에 방해되는가? 만약 그렇다면 이 때문에 낮아진 테스트 용이성이 final로 선언해서 얻는 이득보다 큰 것인가?


3. 정적 메서드를 피하라.

정적 메서드 대부분은 사실 정적 메서드가 아니었어야 한다.

스텁으로 만들고 싶은 메서드는 정적 메서드로 만들지 않는다. random int를 리턴하는 정적메서드가 있다면 임의성은 자동화된 테스트에서 피해야 할 요소이니 테스트에서 스텁으로 교체하고자 할 것이다. 이런 경우는 정적 메서드로 만들지 않는다.

정적메서드는 만들기는 쉽지만, 나중에 테스트에서 스텁으로 교체하고 싶을 경우엔 꽤 골치아프다.


4. new는 신중하게 사용하라.

하드코딩의 가장 흔한 형태가 바로 new 키워드다.테스트 더블로 대체할 가능성이 없는 객체만 직접 생성해야한다.


5. 생성자에서는 로직 구현을 피하라.

생성자에는 단위 테스트에서 교체해야 할만한 코드는 절대 넣어서는 안 된다.

만약 이런 코드를 발견하면 일반 메서드로 추출하거나 외부에서 객체 형태로 입력받게끔 수정하여 테스트에서 원하는 대로

바꿔칠 수 있도록 해야 한다.


6. 싱글톤을 피하라.

싱글톤 패턴은 테스트가 자신에게 필요한 대용품을 만들 수 없게 가로막기도 한다.


7. 상속보다는 컴포지션을 사용하라.

상속으로 코드를 재사용할 수 있는 건 맞지만, 그렇게 만들어진 클래스 계층 구조는 변경할 수 없으므로 테스트 용이성을 떨어트린다. 상속의 용도는 다형성이지 코드 재사용이 아니다.


8. 외부 라이브러리를 감싸라


9. 서비스 호출을 피하라

서비스를 정적으로 호출하지말자. 생성자에 종속 객체를 직접 전달하는 것을 고려하자.