<div id="readability-page-1" class="page"><div id="content">
		<main id="main" role="main">

		
			<article id="post-1879">
			
		<div>
			
<p><a href="https://github.com/testdouble/contributing-tests/wiki/Don't-mock-what-you-don't-own">https://github.com/testdouble/contributing-tests/wiki/Don’t-mock-what-you-don’t-own</a></p>



<p>이 글에선 사람들이 테스트에서 가져오기 힘든 실제의 것을 mocking 해서 쓰는 행동이 잘못되었다고 지적하고 있다. 테스트 더블을 사용하는 근본적인 이유는 테스트 대상이 의존하고 있는 인터페이스와 적절하게 소통하고 있는지 확인하기 위해서 이기 때문이다.</p>



<p>테스트 더블은 아직 구현되지 않은 것을 의존하는 테스트 대상을 위해서 안전하고 ‘쉽게 수정할 수 있는’ 테스트 용 객체를 제공하기 위해 탄생했다. 그리고 왜 쉽게 수정할 수 있어야 하냐면, 테스트 더블의 최종 목적은 의존하고 있는 인터페이스의 설계가 제대로 되었는지 알려주기 위해서 이기 때문이다. 이는 테스트 더블을 가지고 테스트 대상에서 의존하는 코드를 짤 때 코드 스멜을 통해 설계에 문제가 있음을 알 수 있다.</p>



<p>그래서 서드파티 의존성을 테스트 더블로 교체하는 것은 이런 본래 목적에 맞지 않다. 만약 서드파티 의존성을 가짜로 만들어서 테스트하는데 문제가 없었다면, 서드파티 의존성과의 결합도가 너무 높은 것일 수 있다. 반대로 의존성을 가짜로 만들어서 테스트하는게 힘들었다면, 그만큼 서드파티 의존성을 재현하려고 고생해서 만들었을 텐데 그렇게 만든 테스트 더블은 사실 별 가치가 없다. 의존하는 부분의 설계가 잘 된 걸 알려주지 않기 때문이다.</p>



<p>그래서 이 글에선 실제의 것을 바로 mocking하지 말고 adapter, wrapper, shim 같은 걸 직접 만들어서 그걸로 서드파티 의존성을 감싸라고 말한다. 이러면 서드파티 의존성을 쉽고 일관적인 방법으로 사용할 수 있다. 예로 들어 의존성을 method chaining 구조로 만들어야 한다든지, 여러 단계로 호출해야 한다든지, 반복적인 기본값 설정을 줘야 된다든지 하는 부분을 adapter로 감싸면, 이 adapter를 사용하는 입장에선 매우 편해진다.</p>



<p>이렇게 adapter를 쓰는 건 다른 이점도 있다. 만약 의존성이 수많은 기능을 제공하는데 그 중 일부만 사용한다면, adapter에도 이 일부 기능만 구현할 것이다. 그러면 다른 의존성으로 교체할 때도, adapter에서 제공하는 이 몇몇 기능만 열어주면 쉽게 교체할 수 있다. 게다가 기능에 관련된 설정들을 모아서 관리할 수도 있어서 편하다.</p>
			
			
								</div>
</article>

			
	<nav aria-label="글">
		<h2>글 네비게이션</h2>
		
	</nav>
			

		
		</main>
	</div></div>

Wraithkim의 지식공방

https://github.com/testdouble/contributing-tests/wiki/Don’t-mock-what-you-don’t-own 이 글에선 사람들이 테스트에서 가져오기 힘든 실제의 것을 mocking 해서 쓰는 행동이 잘못되었다고 지적하고 있다. 테스트 더블을 사용하는 근본적인 이유는 테스트 대상이 의존하고 있는 인터페이스와 적절하게 소통하고 있는지 확인하기 위해서 이기 때문이다. 테스트 더블은 아직 구현되지 않은 것을 의존하는 테스트 대상을 위해서 안전하고 ‘쉽게 수정할 수 있는’ 테스트 용 객체를 제공하기 위해 탄생했다. 그리고 […]

당신이 소유하지 않은 걸 mocking하지 마시오

댓글