[Clean Architecture] 28장 :: 테스트 경계

Jihyoung·2022년 4월 27일

Clean Architecture

목록 보기

23/23

작은 테스트 이든, 대규모 테스트이든 아키텍처적으로 모두 동등하다.
테스트는 의존성 규칙을 따른다.
- 의존성은 항상 테스트 대상이 되는 코드를 향한다.
  - 실제로 테스트는 아키텍처에서 가장 바깥쪽 원에 해당되며 시스템 내부의 어떤것도 테스트에 의존하지 않는다.
독립적으로 배포가 가능하다.
시스템 컴포넌트 중 가장 고립되어 있다.
- 시스템 운영에 필수는 아니다.
- 개발 지원에 가깝다.

테스트와 시스템의 설계가 잘 통합되어있지 않는다면 테스트는 깨지기 쉽고 시스템은 변경하기 어려워진다.
: 강하게 결합되어 있으면 수정에 문제가 생길 수 있다.

변동성이 있는것에 의존하지 않게 설계해야 한다.
ex) 변동성이 큰 GUI 를 의존하지 않고 업무 규칙을 의존하여 테스트 할 수 있어야 한다.

테스트 API는 테스트를 애플리케이션으로부터 분리할 목적으로 사용된다.

구조적 결합은 테스트 결합 중에서 가장 강하며 상용 클래스나 메서드 중 하나라도 변경되면 다수의 테스트가 변경되어야 한다.
이로 인해 테스트는 깨지기 쉬워지며 코드는 뻣뻣해진다.

테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨겨 상용코드를 리팩터링하거나 진화시키더라도 테스트에는 전혀 영향을 주지 않는것에 있다. (반대의 경우에도 적용)

테스트는 더 구체화 될 것이고, 상용 코드는 더 추상적으로 변화될 것이기 때문에 별도로 진화할 수 있도록 해야한다.

테스트 API 를 운영 시스템에서 분리하고 테스트 API 중 위험한 부분의 구현부는 독립적으로 배포할 수 있는 컴포넌트로 분리해야 한다.

테스트는 시스템의 일부이다. 따라서 테스트에서 기대하는 안정성과 회귀의 이점을 얻으려면 테스트를 잘 설계해야 한다.
-> 테스트는 유지보수에 용이하게 잘 설계해야 한다.

로그를 생활화