시스템 컴포넌트인 테스트

• 아키텍처 관점에서는 모든 테스트가 동일
• 테스트는 태생적으로 의존성 규칙을 따른다
• 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각 가능
• 테스트는 독립적으로 배포 가능
• 시스템 컴포넌트 중에서 가장 고립. 어떤 사용자도 테스트에 의존 X

테스트를 고려한 설계

• 테스트가 시스템의 설계와 잘 통합되지 않으면 테스트는 깨지기 쉬워지고, 시스템은 변경하기 어려워짐
• 깨지기 쉬운 테스트는 시스템을 뻣뻣하게 만드는 부작용을 낳는다
• 변동성 있는 것에 의존하지 말아야 하므로 GUI 보다는 업무 규칙을 테스트 할 수 있게 해야 한다

테스트 API

• 테스트가 모든 업무 규칙을 검증하는 데 사용할 수 있도록 특화된 API를 만들면 된다
• 이러한 API는 보안 제약사항을 무시할 수 있으며 값비싼 자원은 건너뛰고, 테스트 가능한 특정 상태로 강제하는 강력한 힘을 지녀야 한다
• 이 API는 사용자 인터페이스가 사용하는 인터랙터와 인터페이스 어댑터들의 상위 집합
• 테스트 구조를 애플리케이션 구조로부터 결합을 분리하는 게 목표

구조적 결합

• 구조적 결합은 테스트 결합 중에서 가장 강하며, 가장 은밀하게 퍼져 나가는 유형
• 테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨기는 데 있다
• 이러면 상용 코드를 리팩터링하거나 진화시키더라도 테스트에는 영향 X
• 테스트를 리팩터링하거나 진화시킬 때도 상용 코드에는 영향 X