“CleanArchitecture 28장”
시스템 컴포넌트인 테스트
- 테스트는 아키텍처 적으로 모두 동등
- 테스트는 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향함
- 아키텍처에서 가장 바깥쪽 원
- 시스템 내부의 어떤 것도 테스트를 의존하지 않음
- 시스템의 컴포넌트를 향해 항상 원의 안쪽으로 의존
- 독립적으로 배포 가능
- 시스템 컴포넌트 중에 가장 고립 : 시스템의 운영에 꼭 필요하지 않음
그렇다고 해서 테스트가 시스템 컴포넌트가 아니라는 뜻은 아니다. 사실 많은 면에서 테스트는 다른 모든 시스템 컴포넌트가 반드시 지켜야 하는 모델을 표현 해준다.
테스트를 고려한 설계
개발자는 종종 테스트가 시스템의 설계 범위 밖에 있다고 여긴다.
그러나 테스트가 시스템의 설계와 잘 통합되지 않으면, 테스트는 깨지기 쉬워지고, 시스템은 뻣뻣해져서 변경하기 어려워진다.
문제는 “결합” 이다.
깨지기 쉬운 테스트 문제
- 시스템에 강하게 결합된 테스트 -> 시스템 변경시 함께 변경
- 시스템 컴포넌트의 작은 변경 -> 수많은 테스트 망가뜨림
- 시스템을 뻣뻣하게 만듬
테스트를 고려한 설계
- 변동성이 있는 것에 의존하지 말라
테스트 API
이 목표를 달성하려면 ?
테스트가 모든 업무 규칙을 검증하는데 사용할 수 있도록 특화된 API
- 보안 제약 사항 무시
- 값비싼 자원 건너뜀 (ex DB)
- 시스템을 테스트 가능한 상태로 강제
- 테스트를 애플리케이션으로부터 분리할 목적으로 사용
- 테스트 구조를 애플리케이션 구조로부터 결합을 분리
구조적 결합
테스트 API 역할은 애플리케이션의 구조를 테스트로부터 숨기는데 있다
이렇게 되면,
상용코드를 리팩터링하거나 진화 <-> 테스트를 리팩터링 하거나 진화
서로 영향을 주지 않는다.
시간이 갈수록 테스트는 더 구체적이고 특화된 형태로 변하며 상용코드는 더 추상적이고 범용적인 형태로 변하기 때문에 따로 진화할 수 있다는 점은 필수적이다.
보안
테스트 API 를 운영 시스템에 배포하면 위험하며 이를 피하기 위해 테스트 API 자체와 테스트 API 중 위험한 부분의 구현부는 독립적으로 배포할 수 있는 컴포넌트로 분리해야 한다.
결론
테스트는 시스템의 외부에 있지 않다. 오히려 시스템의 일부다.
