[책] 구글 엔지니어는 이렇게 일한다
구글 엔지니어는 이렇게 일한다 - 한빛미디어
13.5 실제 구현
구글은 모의 객체 중심주의 테스트에서 실제 구현을 선호하는 고전적 테스트 방식을 채택.
실제 구현 사용 판단 기준
실행 시간
실제 구현을 사용하고, 만약 테스트가 너무 느려졌다고 판단되는 경우 테스트 대역 사용
결정성
결정적 테스트 : 같은 버전의 시스템을 대상으로 실행하면 언제든 똑같은 결과를 내어주는 테스트
실제 구현은 테스트 대역보다 훨씬 복잡할 수 있어 비결정적일 가능성 존재.
- 스레드 순서 영향을 받는 멀티스레드, 외부 서비스 의존 코드, 시스템 클록 등
의존성 생성
실제 구현 이용 시 의존 대상 모두 생성해야하는 문제. Mockito 이용 시 @Mock으로 쉽게 대역 생성 가능. 다만, 실제 구현/대역 사용은 트레이드오프를 고려해 결정 필요.
13.6 속이기(가짜 객체)
가짜 객체는 테스트의 속도를 높여줌.
가짜 객체를 사용하려는 경우 유지보수 비용까지 같이 고려해야 함.
가짜 객체가 실제 구현의 행위를 얼마나 비슷하게 흉내 내느냐. 대체하려는 API의 명세를 충실히 시행하면 됨.
API 소유자가 가짜 객체를 만들 생각이 없는 경우 API를 감싸는 클래스를 직접 작성.
13.7 뭉개기(스텁)
원래는 없는 행위를 테스트가 함수에 덧씌우는 방법.
- when(…).thenReturn(…)
스텁을 과용하면 테스트가 불명확해지고, 깨지기 쉬우며, 테스트 효과가 떨어짐.
스텁이 적합한 경우는 특정 함수 가 특정 값을 반환하도록 하여 대상 시스템을 원하는 상태로 변경하려 할 때
테스트의 목적을 분명하게 드러내려면 스텁된 함수가 직접적인 연관이 있어야. 대체로 적은 수의 함수만 스텁으로 대체. 만약 너무 많으면 리팩토링의 신호로 볼 수도 있음.
13.8 상호작용 테스트
대상 함수의 구현을 호출하지 않으면서 그 함수가 어떻게 호출되는지를 검증하는 기법
상호작용 테스트보다 상태 테스트를 우선할 것.
상호작용 테스트의 문제점
- 특정 함수 호출 여부만 확인. 올바른 작동 확인 불가.
- 대상 시스템의 상세 구현 방식을 활용 => 깨지기 쉬운 테스트
상호작용 테스트 적합 경우 :실제 구현, 가짜 객체 사용 불가, 함수 호출 횟수나 호출 순서가 달라지면 기대와 다르게 동작하는 경우
상호작용 테스트를 적용하게 되는 경우
- 상태 변경 함수일 경우에만 상호작용 테스트 우선 고려 : 상태 유지 테스트는 다른 테스트와 중복 가능성 높음.
- 너무 상세한 테스트는 피할 것
13.10 핵심
- 테스트 대역보다
실제 구현사용 - 실제 구현 사용 불가 경우
가짜 객체 - 스텁 과용 시 테스트 불명확, 깨지기 쉬움
- 상호작용 테스트는 되도록 지양.
