28장 테스트 경계

시스템 컴포넌트인 테스트

아주작은 테스트이든, TDD이든 대규모이든 아키텍처적으로는 관점으로는 모두 동일하게 봄.

테스트의 의존성은 항상 테스트 대상이 되는 코드를 향하기 때문에 가장 바깥쪽 원으로 생각할 수 있음.

테스트는 독립적으로 배포가 가능함.

테스트는 시스템 컴포넌트 중 가장 고립되어 있으며 테스트가 시스템운영에 꼭 필요한것은 아님.

→ 어떤사용자도 테스트에 의존하지 않기 때문이며 운영이아닌 개발을 지원하기 때문.

테스트는 시스템의 설계 범위 밖에 있지않음. 그러나 시스템에 강하게 결합되어 버린 테스트라면

시스템 컴포넌트가 사소하게 변경하더라도 이와 결합된 수 많은 테스트가 깨질 수 있음.

그러므로 개발자는 시스템을 변경하지 않으려 할것이며 이로인해 시스템은 뻣뻣해질 것임.

해결책은 변동성이 있는것에 의존하지 않으면 됨.(항상 나오는 아키텍처 설계의 첫번째 규칙)

변동성이 큰 GUI를 의존하지 않고 업무규칙을 의존하여 테스트할 수 있게 해야함.

위의 목표를 달성하려면 값비싼 자원(DB)은 건너뛰고 보안 제약사항은 무시하며 모든 업무 규칙을 검증할 수 있는 API를 만들면됨. 테스트 API는 테스트를 애플리케이션으로부터 분리할 목적으로 사용됨.

구조적 결합은 테스트 결합 중에서 가장 강하며 상용 클래스나 메서드 중 하나라도 변경되면 다수의 테스트가 변경되어야 함.

테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨겨 상용코드를 리팩터링 하더라도 테스트에는 전혀 영향을 주지 않는것에 있음.(반대도 마찬가지)

구조적 결합을 약하게하여