파이썬으로 살펴보는 아키텍처 패턴

117

5

장

높은 기어비와 낮은 기어비의 TDD

4

장에서는 서비스 계층으로 작동하는 애플리케이션에 필요한 오케스트레이션 책임 일부를 분

리했다. 서비스 계층을 사용하면 각각의 유스 케이스와 워크플로를 명확히 정의할 때 도움이

된다. 정의할 수 있는 내용으로는 저장소에서 얻을 필요가 있는 데이터가 무엇인지, 어떤 사전 검

사와 현재 상태 검증을 필수적으로 해야 할지, 마지막에 어떤 내용을 저장해야 할지 등이 있다.

하지만 현재 단위 테스트는 저수준에서 작동하며 모델에 직접 작용한다. 이번 장에서는 이런

테스트를 더 상위 계층으로 끌어올리면 발생하는 트레이드오프와 더 많은 일반적인 테스트 지

침에 대해 논의한다.

해리의 경험: 테스트 피라미드가 실제 작동하는 모습을 본 순간 ‘아하!’하고 깨닫게 되었다.

다음은 해리가 직접 한 말이다.

처음에는 밥이 이야기한 모든 아키텍처 패턴에 대해 회의적이었다. 하지만 실제 테스트 피라미

드가 작동하는 모습을 보고 생각이 바꼈다.

일단 도메인 모델링과 서비스 계층을 구현하고 나면 실제로 단위 테스트의 수가 통합 테스트와

엔드투엔드 테스트의 수를 열 배 이상 능가하는 단계에 도달하게 된다.

E2E

테스트를 빌드하는

데 몇 시간씩 걸리던 곳(“내일까지 기다려줘”라는 말이 필수적인)에서 일했기 때문에 모든 테스

트를 몇 초나 몇 분 내에 ...