<div id="readability-page-1" class="page"><article id="post-1804">
			
		<div>
			




<h2 id="tdd의-고단-기어와-저단-기어">TDD의 고단 기어와 저단 기어 </h2>



<p>이전 장까지 단위 테스트와 서비스 계층 테스트, E2E 테스트 에 대한 설명을 했다. 하지만 책에서 만들었던 테스트 코드들은 도메인 계층에 많이 의존하고 있다. 만약 서비스 계층을 테스트하는 거라면 도메인 계층에 의존해야 할까? 도메인 계층 위주의 세분화된 테스트는 E2E나 서비스 계층 테스트 보다 무조건 좋을까? 이번 장에선 테스트 대상 외의 의존을 줄이는 방법과 테스트 피라미드에 대해서 배운다.</p>



<h3 id="테스트-피라미드">테스트 피라미드</h3>



<p>책에선 지금까지 짠 테스트 개수를 단위, 통합, E2E 테스트로 범주를 나눠서 확인하고, 테스트 피라미드 상 건강하다고 본다. 여기서 테스트 피라미드는 이 세 범주가 균형이 잡혀있는지 확인하는 것이다.</p>



<figure><img src="https://martinfowler.com/bliki/images/testPyramid/test-pyramid.png" alt="" width="474" height="254"></figure>



<p>이러한 개념이 나온 배경은 다음과 같다. 위 그림에선 E2E 테스트 대신 UI 테스트를 예로 들었는데, UI 테스트는 적절한 GUI 테스팅 도구만 있다면 작성하기 쉽다. 하지만 UI 테스트를 남용하면 안되는데, 그 이유는 GUI 도구들의 구매 비용, 오래 걸리는 테스트, 그리고 대개 비결정적 테스트이기 때문에 버그를 찾는데 어렵기 때문이다.</p>



<p>그래서 비록 단위 테스트가 작성하기 어렵지만 테스트 시간과 비용, 정밀한 오류 추적을 위해 충분히 작성할 필요가 있다. 하지만 UI 테스트 또한 단위 테스트를 실수로 잘못 짰을 때를 위한 2차 방어선 역할을 해줄 수 있다. 그리고 통합 테스트는 가운데서 단위 테스트와 UI 테스트를 보완해 줄 수 있다. 이에 대한 자세한 설명은 다음에 나온다.</p>



<p>더 자세한 설명은 다음 글에서 확인할 수 있다. <a href="https://martinfowler.com/bliki/TestPyramid.html">https://martinfowler.com/bliki/TestPyramid.html</a></p>



<h3 id="고단-기어와-저단-기어">고단 기어와 저단 기어</h3>



<p>책에선 마치 자전거가 속도를 받으면 기어를 바꾸는 것처럼 테스트도 경우에 따라 도메인 모델의 의존도를 줄여야 된다고 말한다.</p>



<p>예로 들어 프로젝트 초기에 도메인 모델을 새로 만들어야 할 때, 도메인 모델을 대상으로 하는 테스트는 도메인 모델에 대한 정보를 쉽게 보여주고, 빠르고 상세한 피드백을 줄 수 있다.</p>



<p>하지만 시간이 지나면 서비스 계층 테스트를 추가한다. 더 넓은 범위를 테스트 할 수 있고, 도메인 모델과의 결합을 줄여서 도메인 모델을 변경 할 때 같이 수정할 일이 줄어든다.</p>



<p>(기존의 도메인 모델 테스트를 수정하는 게 아니고 기존 테스트들을 포함하고 도메인 모델에 의존하지 않는 서비스 계층 테스트를 만든다. 그러면 나중에 도메인 모델이 변경될 때, 굳이 기존 테스트를 수정하지 않고 버려도 된다.)</p>



<p>하지만 진행 도중 큰 문제에 부딪히면 다시 우리의 의도가 맞는지 깊게 확인해야 하고, 더 상세한 피드백이 필요해진다. 그러면 단위 테스트를 만들 때다.</p>



<h3 id="서비스-계층-테스트에서-도메인-결합-떼기">서비스 계층 테스트에서 도메인 결합 떼기</h3>



<p>이전 장 까지의 책의 예제에선 서비스 계층 테스트가 도메인 모델을 의존하고 있었다. 그래서 결합을 떼내는 방법을 설명한다.</p>



<ul><li>인자로 받는 모델은 primitive 타입의 변수들로 바꾸기</li><li>내부에서 테스트 데이터로 생성할 땐 helper function이나 fixture로 감추기<br>(이 helper function도 primitive 타입으로 받기)</li><li>필요하면 새로운 서비스를 만들어서 호출하기<br>ex) 할당을 위한 Batch가 DB에 있어야 하면 DB에 Batch를 추가하는 서비스 구현</li></ul>



<h3 id="e2e-테스트도-개선하기">E2E 테스트도 개선하기</h3>



<p>E2E 테스트도 서비스 계층 테스트와 마찬가지로 도메인 모델과의 결합을 제거하는 게 도메인 모델을 수정 시의 변경 비용을 줄일 수 있다. 책에선 앞서 만든 서비스를 API까지 만들어서 기존의 E2E 테스트에서 직접 DB에 접근하는 코드를 수정했다.</p>



<h3 id="결론-여러-종류의-테스트를-넣는-규칙">결론</h3>



<p id="결론-여러-종류의-테스트를-넣는-규칙">여러 종류의 테스트를 넣는 규칙</p>



<ol><li>기능 하나에 E2E 테스트 하나는 있어야 한다.</li><li>테스트의 대부분은 서비스 계층을 대상으로 만들자</li><li>도메인 모델을 위한 테스트는 핵심적인 것들은 유지하자</li><li>실패하는 경우는 오류 처리 방법을 기준으로 기능을 정한다.<br>(이 어플리케이션에선 모든 오류들이 HTTP 400 하나로 처리된다. 따라서 각각의 기능마다 정상 케이스를 테스트하지만 모든 실패 케이스는 하나의 E2E 테스트로 묶는다)</li></ol>



<p>그 외에</p>



<ul><li>서비스 계층에선 도메인 객체를 원시 타입으로 표현하기</li><li>이상적으론 서비스 계층에선 서비스 만으로 테스트 해야 한다. 저장소를 직접 접근하지 말아야 한다. E2E도 마찬가지다.</li></ul>
			
			
								</div>
</article></div>

Wraithkim의 지식공방

TDD의 고단 기어와 저단 기어 이전 장까지 단위 테스트와 서비스 계층 테스트, E2E 테스트 에 대한 설명을 했다. 하지만 책에서 만들었던 테스트 코드들은 도메인 계층에 많이 의존하고 있다. 만약 서비스 계층을 테스트하는 거라면 도메인 계층에 의존해야 할까? 도메인 계층 위주의 세분화된 테스트는 E2E나 서비스 계층 테스트 보다 무조건 좋을까? 이번 장에선 테스트 대상 외의 의존을 […]

Architecture Patterns with Python – 6

댓글