5-14. 테스트 경계

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

 

시스템 컴포넌트인 테스트

테스트는 시스템의 일부인가?

아니면 별개인가?

어떤 종류의 테스트가 있는가?

단위 테스트와 통합 테스트는 서로 다른가?

인수 테스트, 기능 테스트, Cucumber 테스트, TDD 테스트, BDD 테스트, 컴포넌트 테스트 등은 어떻지?

아키텍처 관점에서는 모든 테스트가 동일하다. TDD로 생성한 아주 작은 테스트이든, 아니면 대규모의 테스트이든, 이들 테스트는 아키텍처적으로 모두 동일하다.

 

테스트는 태생적으로 의존성 규칙을 따른다. 테스트는 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향한다. 실제로 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다.

시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다.

 

또한 테스트는 독립적으로 배포 가능하다.

사실 대다수의 경우 테스트는 테스트 시스템에만 배포하며, 상용 시스템에는 배포하지 않는다.

따라서 심지어 배포 독립성이 달리 필요하지 않은 시스템에서도 테스트는 독립적으로 배포될 것이다.

 

테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다.

테스트가 시스템 운영에 꼭 필요치는 않다. 어떤 사용자도 테스트에 의존하지 않는다.

테스트의 역할은 운영이 아니라 개발을 지원하는 데 있다.

그렇다고 해서 테스트가 시스템 컴포넌트가 아니라는 뜻은 아니다.

사실 많은 면에서 테스트는 다른 모든 시스템 컴포넌트가 반드시 지켜야 하는 모델을 표현해준다.

 

테스트를 고려한 설계

테스트가 지닌 극단적인 고립성이 테스트는 대체로 배포하지 않는다는 사실과 어우러지며, 개발자는 종종 테스트가 시스템의 설계 범위 밖에 있다고 여긴다. 이 관점은 치명적이다.

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

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

상황은 거 심각해질 수 있다. 시스템의 공통 컴포넌트가 변경되면 수백, 심지어 수천 개의 테스트가 망가진다. 이 문제는 깨지기 쉬운 테스트 문제로 알려져 있다.

 

이 문제가 어떻게 발생하는지 보는 일은 어렵지 않다. 예를 들어 GUI를 사용하여 업무 규칙을 검증하는 테스트 스위트가 있다고 해보자. 이러한 테스트들은 로그인 화면에서 시작해서 페이지 구조를 탐색해 나가면서 특정 업무 규칙을 검사한다. 따라서 로그인 페이지나 탐색 구조 어딘가가 달라지면 엄청난 수의 테스트가 망가진다.

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

시스템에 가한 간단한 변경이 대량의 테스트 실패로 이어진다는 사실을 알게 되면, 개발자는 그러한 변경을 하지 않으려고 할 것이다.

 

예를 들어 마케팅팀에서 페이지 구조를 살짝 손봐달라고 요청했는데, 이로 인해 망가지는 테스트가 1,000개라면 두 팀 사이의 대화가 어떨지를 상상해 보자.

이 문제를 해결하려면 테스트를 고려해서 설계해야 한다. 소프트웨어 설계의 첫 번째 규칙은 언제나 같다.

변동성이 있는 것에 의존하지 말라. GUI는 변동성이 크다.

GUI로 시스템을 조작하는 테스트 스위트는 분명 깨지기 쉽다. 따라서 시스템과 테스트를 설계할 때, GUI를 사용하지 않고 업무 규칙을 테스트할 수 있게 해야 한다.

 

테스트 API

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

테스트 API는 테스트를 애플리케이션으로부터 분리할 목적으로 사용한다. 단순히 테스트를 UI에서 분리하는 것만이 아닌, 테스트 구조를 애플리케이션 구조로부터 결합을 분리하는 게 목표다.

 

구조적 결합

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

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

상용 클래스나 메서드 중 하나라도 변경되면 딸려 있는 다수의 테스트가 변경되어야 한다. 결과적으로 테스트는 깨지기 쉬워지고, 이로 인해 상용 코드를 뻣뻣하게 만든다.

 

테스트 API의 역할은 애플리케이션의 구조를 테스트로부터 숨기는 데 있다. 이렇게 만들면 상용 코드를 리팩터링하거나 진화시키더라도 테스트에는 전혀 영향을 주지 않는다. 또한 테스트를 리팩터링하거나 진화시킬 때도 상용 코드에는 전혀 영향을 주지 않는다.

 

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

하지만 구조적 결합이 강하면 필수적인 진화 과정을 방해할 뿐만 아니라, 상용 코드의 범용성와 유연성이 충분히 좋아지지 못하게 막는다.

 

보안

테스트 API가 지닌 강력한 힘을 운영 시스템에 배포하면 위험에 처할 수 있다.

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

 

결론

테스트는 시스템 외부에 있지 않다.

오히려 시스템의 일부다. 따라서 테스트에서 기대하는 안정성과 회귀의 이점을 얻을 수 있으려면 테스트는 잘 설계되어야만 한다. 테스트를 시스템의 일부로 설계하지 않으면 테스트는 꺠지기 쉽고 유지보수하기 어려워지는 경향이 있다.

이러한 테스트는 유지보수하기가 너무 힘들기 때문에 결국 방바닥의 휴지처럼 버려지는 최후를 맡는다.