‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
- 테스트는 시스템의 일부이며, 아키텍처에도 관여한다.
시스템 컴포넌트인 테스트
- TDD로 생성한 아주 작은 테스트든, 대규모의 FitNesse, Cucumber 테스트든 이들 테스트는 아키텍처 관점에서 모두 동등하다.
- 테스트는 태생적으로 의존성 규칙을 따른다.
- 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향한다.
- 실제로 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다.
- 시스템 내부 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다.
- 또한 테스트는 독립적으로 배포 가능하다.
- 사실 대다수의 경우 테스트는 테스트 시스템에만 배포하며, 상용 시스템에는 배포하지 않는다.
- 따라서 심지어 배포 독립성이 필요치 않은 시스템에서도 테스트는 독립적으로 배포될 것이다.
- 테스트는 시스템 컴포넌트중 가장 고립되어 있다.
- 테스트가 시스템 운영에 꼭 필요치 않다.
- 테스트의 역할은 운영이 아니라 개발을 지원하는데 있다.
- 사실 많은 면에서 테스트는 다른 모든 시스템 컴포넌트가 반드시 지켜야 하는 모델을 표현해준다.
테스트를 고려한 설계
- 개발자는 종종 테스트가 시스템의 설계 범위 밖에 있다는 치명적인 생각을 한다.
- 테스트가 시스템 설계와 잘 통합되지 않으면 테스트는 깨지기 쉬워지고, 뻣뻣해져 변경하기 어려워진다.
- 물론 문제는 결합이다.
- 시스템에 강하게 결합된 테스트라면 시스템이 변경될때 함께 변경되어야만 한다.
- 시스템 컴포넌트에서 생긴 아주 사소한 변경도, 이와 결합된 수많은 테스트를 망가뜨릴 수 있다.
- 상황은 더 심각해질 수 있다.
- 시스템의 공통 컴포넌트가 변경되면 수백, 심지어 수천 개의 테스트가 망가진다.
- 문제는
깨지기 쉬운 테스트 문제(Fragile Tests Problem)로 알려져 있다.
- 예를 들어, GUI 를 사용하여 업무 규칙을 검증하는 테스트 스위트가 있다 해보자.
- 이러한 테스트들은 로그인 화면에서 시작해서 페이지 구조를 탐색해 나가면서 특정 업무 규칙을 검사한다.
- 따라서 로그인 페이지나 탐색 구조 어딘가가 달라지면 엄청난 수의 테스트가 망가진다.
- 깨지기 쉬운 테스트는 시스템을 뻣뻣하게 만든다는 부작용을 낳을 때가 많다.
- 시스템에 가한 간단한 변경이 대량의 테스트 실패로 이어진다는 사실을 알게 되면, 개발자는 그러한 변경을 하지 않으려 들 것이다.
- 예를 들어 마케팅팀에서 페이지 탐색 구조를 살짝 손봐달라고 요청했는데, 이로 인해 망가지는 테스트가 1000개라면 두 팀 사이의 대화가 어떻게 될지 상상해보자..
- 이 문제를 해결하려면 테스트를 고려해서 설계해야 한다.
- 소프트웨어 설계의 첫번쨰 규칙은 언제나 같다. “변동성 있는 것에 의존하지 말라.”
- GUI 는 변동성이 크다. GUI 로 시스템을 조작하는 테스트 스위트는 분명 깨지기 쉽다.
- 따라서 시스템과 테스트를 설계할때, GUI 를 사용하지 않고 업무 규칙을 테스트할 수 있게 해야 한다.
테스트 API
- 위 목표를 달성하려면 값 비싼 자원(DB)은 건너뛰고 보안 제약사항은 무시하며 모든 업무 규칙을 검증할 수 있는 API를 만들면 된다.
- 그리고 이 테스트 API 는 시스템을 테스트 가능한 특정 상태로 강제하는 강력한 힘을 지녀야 한다.
- 테스트 API는 테스트를 애플리케이션으로부터 분리할 목적으로 사용됨.
- 단순히 UI 로부터 분리하는 것만이 아닌..
구조적 결합
- 테스트 결합 중에 가장 강하다.
- 테스트 스위트는 애플리케이션 구조에 강하게 결합되어 잇다.
- 상용 클래스나 메서드중 하나라도 변경되면 딸려 있는 다수의 테스트도 깨지게 되고, 상용 코드를 뻣뻣하게 만든다.
- 테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨겨 상용코드를 리팩터링 하더라도 테스트에는 전혀 영향을 주지 않는것에 있다.
보안
- 운영 시스템에 배포하면 위험에 처할 수 잇기에 테스트 API 자체와 테스트 API 중 위험한 구현부는 독립적으로 배포할 수 있는 컴포넌트로 분리한다.