테스트 경계

28. 테스트 경계

시스템 컴포넌트인 테스트

아키텍처 관점에서 모든 테스트는 동일

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

의존성은 항상 테스트 대상이 되는 코드를 향함

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

테스트는 독립적으로 배포 가능

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

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

테스트를 고려한 설계

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

문제는 결합

시스템의 공통 컴포넌트가 변경되면 수백, 수천 개의 테스트가 망가진다. -> 깨지기 쉬운 문제(Fragile Tests Problem)

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

이 문제를 해결하려면 테스트를 고려해서 설계해야 한다.

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

테스트 API

테스트가 모든 업무 규칙을 검증하는 데 사용할 수 있도록 특화된 API를 만들면 된다.

이러한 API는 보안 제약사항을 무시할 수 있으며, 값비싼 자원은 건너뛰고, 시스템을 테스트 가능한 특정 상태로 강제하는 강력한 힘을 지녀야 한다.

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

구조적 결합

테스트 결합 중 가장 강하며, 가장 은밀하게 퍼져 나가는 유형

상용 클래스나 메서드 중 하나라도 변경되면 딸려 있는 다수의 테스트가 변경되어야 한다.

결과적으로 테스트는 깨지기 쉬워지고, 이로 인해 상용 코드를 뻣뻣하게 만든다.

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

상용 코드를 리팩터링하거나 진화시키더라고 테스트에는 전혀 영향을 주지 않는다.

따로따로 진화할 수 있다는 점이 필수적

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

보안

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

결론

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

오히려 시스템의 일부다.

테스트를 시스템의 일부로 설계하지 않으면 테스트는 깨지기 쉽고 유지보수하기 어려워지는 경향이 있다.

참조

1. 클린 아키텍처(Clean Architecture)