테스트 경계

테스트는 시스템의 일부이며 아키텍처에도 관여한다.

테스트는 태생적으로 의존성 규칙을 따른다.
테스트는 세부적이며 구체적인것 의존성은 항상 테스트 대상이 되는 코드를 향한다.

테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다.

테스트가 지닌 극단적인 고립성이 테스트는 대체로 배포하지 않는다는 사실과 어우러지며
개발자는 종종 테스트가 시스템 설계 범위 밖에 있다고 생각한다.

테스트가 시스템의 설계와 잘 통합되지 않으면 테스트는 꺠지지 쉬워지고 시스템은 뻣뻣해지기 마련이다.

위에 문제는 결합이 문제를 만든다.

단순히 테스트를 UI에서 분리하는 것만이 아닌, 테스트 구조를 애플리케이션 구조로부터 결합을 분리하는게 목표다.

구조적 결합은 테스트 결합중에서 가장 강하며 가장 은밀하게 퍼져나가는 유형이다.

상용클래스나 메서드 중 하나라도 변경되면 딸려 있는 다수의 테스트가 변경 되어야 한다.
결과적으로 테스트는 꺠지기 쉬워지고 이로 인해 상용코드를 뻣뻣하게 만든다.

테스트 API의 역활은 애플리케이션 구조를 테스트로 부터 숨기는데 있다.

시간이 지날수록 테스트 코드는 더 구체적이고 더 특화된 형태로 변할것이고
상용 코드는 더 추상적이고 더 범용적인 형태로 변할 것이기 때문이다.

테스트 API가 지닌 강력한 힘을 운영시스템에 배포하면 위험에 처할 수 있다.
위험을 피할려면 독립적으로 배포할수 있는 컴포넌트로 분리 해야 한다.

참조