Clean Architecture 정리 - 5부 28장 테스트 경계

테스트와 아키텍처

아키텍처 관점에서 테스트는 모두 동등함.

가장 바깥 원에 존재하며, 시스템 내부에 의존하지 않음.

---

테스트의 독립성

테스트는 상용 시스템과 무관하게 테스트 시스템으로 독립 배포됨.

운영을 위한 것이 아니라, 개발을 지원하기 위해 존재함.

---

테스트를 고려한 설계

시스템에 결합된 테스트는 시스템 변경 시 함께 수정돼야 함.

사소한 컴포넌트 변경에도 수백~수천 개 테스트가 깨짐.

이 문제는 Fragile Tests Problem이라 불림.

 

결국, 테스트가 많을수록 시스템 수정이 어려워짐.

개발자는 코드를 바꾸는 것을 꺼리게 됨.

 

테스트를 고려해 설계할 것.
변동성이 있는 것에 의존하지 말 것.

---

테스트 API

테스트를 쉽게 만들고 유지하려면, 테스트 전용 API가 필요함.

 

업무 규칙 검증에만 집중된 API로, 보안 제약이나 복잡한 상태를 우회할 수 있어야 함.
예: DB 초기화, 특정 상태 강제 등

 

목표는 분리

UI뿐 아니라, 애플리케이션 내부 구조와도 테스트 로직을 분리해야 함.

 

구조적 결합

테스트와 애플리케이션이 구조적으로 결합되면, 변경에 따라 테스트도 함께 바뀜.

상용 클래스마다 대응하는 테스트 클래스가 존재하고,
상용 메서드마다 테스트 메서드가 1:1로 결합되면 위험함.

이런 테스트는 사소한 변경에도 쉽게 깨지고, 시스템을 뻣뻣하게 만듦.

 

테스트 API의 역할

애플리케이션 구조를 테스트로부터 숨김.
덕분에 상용 코드를 리팩터링하거나 진화시켜도 테스트에 영향 없음.
테스트 구조를 바꿔도 상용 코드에 영향 없음.

테스트는 점점 더 구체적이고 특화된 형태로 진화함.
상용 코드는 더 일반적이고 범용적인 형태로 진화함.
이 흐름을 따르려면 구조적 결합은 피해야 함.

 

보안 고려

테스트 API가 가진 강한 제어 능력은 운영 환경에선 위험함.
테스트 API는 운영 시스템과 분리된 컴포넌트로 관리해야 함.

---

테스트 api와 관련한 정보를 찾기가 상당히 힘듭니다.

 

레딧에도 질문이 하나 올라와있네요..

https://www.reddit.com/r/ruby/comments/xxe6m6/have_you_implemented_a_testing_api_like_described/

 

이제까지 제가 책을 읽으면서 생각이 든 Test API는

테스트 API는 HTTP API와 같은 외부 통신과 관련한 내용은 아님.
핵심은 테스트와 애플리케이션 구조의 분리와 간단한 setup이 가능한 유연한 테스트 코드 설계임.
간단한 setup에 필요한, 운영 코드와는 다른 강력한 권한을 갖는 코드를 사용할 수 있으니 주의.

이런 의미가 아닌가 싶습니다.

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 28장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.