28. 테스트 경계

테스트는 시스템의 일부이며, 아키텍처에도 관여한다.

시스템 컴포넌트인 테스트

아키텍처 관점에서는 어떠한 종류에 테스트이든 동일하다.

테스트는 태생적으로 의존성 규칙을 따른다.

그렇다고 하더라도 테스트가 시스템 컴포넌트가 아니라는 뜻은 아니며, 다른 모든 시스템 컴포넌트가 반드시 지켜야하는 모델을 표현해준다.

테스트의 극단적인 고립성이 대체로 배포하지 않는다는 사실과 어우러져, 테스트가 시스템의 설계 범위 밖에 있다고 착각한다.

테스트가 시스템 설계와 잘 통합되지 않으면, 테스트는 깨지기 쉬워지고, 시스템은 뻣뻣해져서 변경하기가 어려워진다.

깨지기 쉬운 테스트 문제(Fragile Tests Problem)

시스템에 강하게 결합된 테스트라면 시스템이 변경될 때 함께 변경되어야하므로, 시스템 컴포넌트에 생긴 아주 사소한 변경도, 이와 결합된 수많은 테스트를 망가뜨릴 수 있다.

시스템의 공통 컴포넌트가 변경되면 수백, 심지어 수천 개의 테스트가 망가진다.

깨지기 쉬운 테스트는 시스템을 뻣뻣하게 만든다는 부작용을 낳을 때가 많다.

따라서 이러한 문제를 해결하기 위해 테스트를 고려한 설계가 필요하다.

핵심은 변동성이 있는 것에 의존하지 않는 것이다.

변동성이 큰 GUI같은 것으로 시스템을 조작하는 테스트 스위트는 깨지기 쉽기 때문에 시스템과 테스트를 설계할 때 GUI를 사용하지 않고 업무 규칙을 테스트 할 수 있게 해야한다.

변동성이 적은 방식으로 업무 규칙을 테스트하기 위해 모든 업무 규칙을 검증하는 데 사용할 수 있도록 특화된 API를 만든다.

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

구조적 결합은 테스트 결합 중에서 가장 강하며, 가장 은밀하게 퍼져나가는 유형이다.

모든 상용 클래스에 테스트 클래스가 각각 존재하고, 모든 상용 메서드에 테스트 메서드 집합이 각각 존재하는 테스트 스위트가 있다고 가정할 때 이러한 테스트 스위트는 애플리케이션 구조에 강하게 결합되어있다.

테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨기는 데 있다.

시간이 지날수록 테스트는 계속해서 더 구체적이고 특화된 형태로 변하고, 상용 코드는 더 추상적이고 범용적인 형태로 변하기 때문에 따로따로 진화할 수 있다는 점은 필수적이다.

하지만 구조적 결합이 강하면 위와 같은 진화 과정을 방해한다.

테스트 API를 운영 시스템에 배포하면 위험에 처할 수 있다.

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

테스트는 시스템의 일부이다.

따라서 테스트에서 기대하는 안정성과 회귀의 이점을 얻을 수 있으려면 테스트는 잘 설계 돼야만한다.

테스트를 시스템의 일부로 설계하지 않으면 테스트는 깨지기 쉽고 유지보수하기 어려워지는 경향이 있으며, 이러한 테스트는 유지보수하기 힘들기 때문에 버려지는 최후를 맡는다.