테스트 경계

시스템 컴포넌트인 테스트

• 여러 테스트 종류가 있지만 중요한 것은 아키텍처 관점에서 모든 테스트가 동일하다는 점이다.
• 테스트는 아키텍처에서 가작 바깥쪽 원으로 생각할 수 있다.
  • 시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다.
• 테스트는 독립적으로 배포 가능하다.
• 테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다.
  • 그렇다고 테스트가 시스템 컴포넌트가 아니라는 뜻은 아니다.
  • 많은 면에서 테스트는 다른 모든 시스템 컴포넌트가 반드시 지켜야 하는 모델을 표현해준다.

테스트를 고려한 설계

• 소프트웨어 설계의 첫 번째 규칙은 변동성이 있는 것에 의존하지 말아야 한다는 것이다.
• 따라서 시스템과 테스트를 설계할 때, GUI를 사용하지 않고 업무 규칙을 테스트할 수 있게 해야 한다.
  • GUI는 변동성이 크므로 GUI로 시스템을 조작하는 테스트 스위트는 분명 깨지기 쉽다.

테스트 API

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

구조적 결합

• 구조적 결합이란
  • 모든 상용클래스별로 테스트 클래스가 존재하고, 모든 상용 메서드에 테스트 메서드 집합이 각각 존재하는 테스트 스위트와 같은 결합을 의미.
• 테스트 API의 역할은 이러한 애플리케이션의 구조를 테스트로부터 숨기는 데 있다.
• 이렇게 만들면 상용 코드를 리팩터링하거나 진화시키더라도 테스트에는 전혀 영향을 주지 않는다. 그 반대도 마찬가지.

보안

• 테스트 API 자체와 테스트 API 중 위험한 부분의 구현부는 독립적으로 배포할 수 있는 컴포넌트로 분리해야 한다.

결론

• 테스트는 시스템 외부에 있지 않으며 시스템의 일부이다.