규칙은 소유한 가장 좁고 안정적인 공개 경계에서 깊게 테스트한다
한 규칙의 분기·경계값·거부 조건은 그 규칙을 책임지는 가장 좁고 안정적인 공개 경계에서 충분히 검증한다. 여기서 공개 경계는 언어의 public 표시가 아니라 해당 단위의 실제 사용자가 의존하는 인터페이스다.
상위 계층에서는 같은 규칙을 전수 반복하지 않고 직렬화, 배선, 상태 전이, 실제 의존성처럼 그 계층에서 새로 생기는 위험을 대표 사례로 확인한다.
이 원칙은 하위 테스트 통과를 전체 시스템 성공으로 확대하지 않으면서도, 모든 함수·파일·계층에 같은 사례를 복제하는 일을 피하게 한다. 비슷한 입력이 여러 계층에 있더라도 각 테스트가 막는 고유 위험을 다르게 설명할 수 있으면 필요한 중복일 수 있다.
대체한 의존성과 실제 실행한 경계
통합이라는 이름만으로 실행 범위를 확정하지 않는다. 대역을 둔 테스트는 실제로 호출·검사한 배선과 규칙을 증명할 수 있지만, 대체한 DB·SDK·외부 서비스의 성공까지 증명하지는 않는다. 실제로 실행한 구성요소와 대체한 의존성을 밝히고 필요한 통합 증거를 해당 경계에서 구한다.
소프트웨어 분석설계 - WikiDocs의 단위·통합 설명과 Spring 공식 테스트 문서를 대조했다. 프로젝트의 테스트 대역 원칙을 같은 주장에 연결한 것으로, 별도의 중복 Atomic을 만들지 않는다.
반복되는 변경에서 무엇을 보호하는가
테스트의 회귀 보호와 결함 탐색 - Yosef K의 변경 제약 관점을 적용할 때는 실패가 보호하는 계약을 먼저 설명한다. 소비자가 의존하지 않는 내부 이름·객체 배치·우연한 호출 순서를 고정하면 행동을 유지한 변경에도 협의 비용이 생길 수 있다. 구조 자체가 명시적인 팀 계약이면 그 구조를 검사하는 목적과 범위를 남긴다.
ArchUnit 도입 사례는 외부 변화의 전파를 제한하려고 합의한 레이어 의존을 검사한 경우다. 이때 보호 대상은 팀이 유지하기로 한 구조 계약이며, 우연한 내부 배치와 구별된다. 검사에 표현한 의존 규칙의 통과를 서비스 동작 전체의 정확성으로 확대하지 않는다.
회귀 보호가 있다는 이유로 실제 의존성의 성공을 추정하지 않는다. 대역으로 확인한 배선과 외부 시스템이 수용하는 계약은 위의 경계 구분을 유지한다. 이 해석은 2026-09-20 Source와 기존 공개 경계 원칙을 대조했으며, 현재 프로젝트 테스트의 적정성이나 통과를 일괄 판정한 것이 아니다.
입력을 공유해도 보호하는 자산이 다른 테스트
Vigilantis의 Rule Engine, Golden Dataset, 가드레일, 저장 경계와 시연 테스트는 일부 입력을 공유하지만 보호하는 자산이 다르다. 특정 파일 경로와 시나리오는 프로젝트 Vault에 남기고, 책임 소유 경계와 상위 계층의 고유 위험을 분리하는 원칙만 전역 지식으로 승격한다.
동결 입력과 원본 변화가 답하는 질문
회귀 테스트의 동결 입력은 선택한 계약과 행동을 안정적으로 검증한다. 그 입력을 가져온 원본이 이후 바뀌었는지는 별도의 질문이다. 무관한 원본 변경이 테스트 수집 자체를 실패시키지 않도록 회귀 입력 로딩과 원본 드리프트 검사를 나누고, 계측 준비나 갱신 검토처럼 원본과의 대응을 판단하는 지점에서 차이를 확인한다.
이 분리는 드리프트를 무시하거나 오래된 fixture를 자동으로 유효하다고 선언하는 뜻이 아니다. 원본 변경이 보호하는 계약·입력 영역·기대값에 영향을 주면 fixture와 검증을 함께 갱신한다. 검사를 항상 특정 CLI에만 두라는 규칙으로 일반화하지 않는다.
2026-09-20 SecOps 실험과 기록 보관 결정·프로젝트 Atomic·계측 코드의 해당 경계를 대조해 보강했다. 기존 확인 이력은 유지하며 새로운 테스트 실행을 뜻하지 않는다.
실행기 회귀와 설치된 CLI가 확인하는 서로 다른 위험
Motifcode의 저장소 구조와 이슈·PR 운영 — 공개 팀 프로젝트와의 비교의 바이트 수 수정은 실제 도구 실행기를 통해 문자 종류와 생성·교체의 결과를 검사한다. 별도의 설치 테스트는 패키지를 만든 뒤 빈 디렉터리에 설치하고 명령을 실행해, 소스 테스트만으로 확인하기 어려운 배포 파일·의존성·실행 연결을 검사한다.
두 검사는 규모가 다를 뿐 아니라 보호하는 실패 경로가 다르다. 설치된 CLI를 모의 HTTP 서버와 실행한 결과는 그 배선과 선택한 시나리오의 증거이며 실제 모델의 품질·공급자 연결까지 증명하지 않는다. 이 비교는 공개 테스트 코드와 GitHub 기록을 읽은 것으로, 이번 증류에서 테스트를 재실행한 것은 아니다.
적용 범위와 한계
- 먼저 검증·계산·상태 전이·장애 대응 중 누가 규칙을 소유하는지 찾는다.
- 소유 경계에서는 정상값뿐 아니라 필요한 경계값·거부·실패 분기를 깊게 검증한다.
- 다음 계층에서는 DB 제약, 외부 SDK, 재시도, 최종 응답처럼 새로 추가된 보장을 검증한다.
- E2E에는 핵심 사용자 흐름과 치명적인 실패를 남긴다. 상위 테스트를 없애거나 하위 테스트로 대체하자는 원칙이 아니다.
- 안전·규제·재발 비용이 큰 경로는 같은 행동을 여러 범위에서 의도적으로 검증할 수 있다. 이때도 각 범위가 추가하는 증거를 구분한다.
승격 원문
- 프로젝트: Vigilantis
- 원문: 규칙은 소유한 가장 좁고 안정적인 경계에서 깊게 테스트한다
- 확인일: 2026-09-03
근거
- 테스트 분류 검토 - ChatGPT 공유 대화
- Software Engineering at Google: Unit Testing — 구현 세부보다 단위의 공개 API와 행동을 검증하는 원칙을 대조했다.
- Software Engineering at Google: Larger Testing — 더 큰 테스트가 실제 의존성·배선·충실도에서 별도 위험을 검증하며, 가능한 한 작은 테스트 경계를 선택하는 절충을 확인했다.