2.8 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | the-startup-validator-follows-the-autoconfiguration-root | 시작 검증기는 실제 lifecycle과 assembly 경로에서 실행 여부를 확인한다 | assembly-ownership | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:the-startup-validator-follows-the-autoconfiguration-root |
시작 검증기는 실제 lifecycle과 assembly 경로에서 실행 여부를 확인한다
검증기 파일이 존재하고 그 테스트가 통과한다는 사실을 검증이 실행된다는 증거로 읽는 것을 막는다. 규칙이 많고 잘 테스트되어 있다는 것은 품질의 증거이지 실행의 증거가 아니다.
목적
검증기 파일이 존재하고 그 테스트가 통과한다는 사실을 검증이 실행된다는 증거로 읽는 것을 막는다.
규칙
-
searched direct caller를 확인한다 프로덕션 직접 호출을 찾지 못한 것은 강한 신호지만 그것만으로 runtime 미실행을 확정하지 않는다.
-
assembly와 lifecycle 경로를 함께 확인한다
@Bean·component scan·auto-configuration, lifecycle callback, application event, post processor, framework discovery를 차례로 확인한다. 실제 부팅이 가능하면 condition report와 시작 로그도 함께 본다. -
규칙 수와 실행 여부를 분리해서 본다 규칙이 많고 잘 테스트되어 있다는 것은 품질의 증거이지 실행의 증거가 아니다.
-
시작 실패로 드러나야 할 것이 조용하면 검증기를 의심한다 설정 오류가 기동에서 잡히지 않고 런타임 증상으로만 나타나면, 그 검사가 배선되어 있는지 먼저 본다.
적용 조건
시작 검증기나 설정 검증기를 갖는 모든 능력
능력이 Stable 로 보고되는데 그 검증이 실제로 도는지 확인할 때
예외
의도적으로 라이브러리로만 제공되고 애플리케이션이 직접 호출하도록 설계된 검증기는 여기 해당하지 않는다. 그 경우 호출 방법이 문서에 있어야 한다.
예시
gRPC 플랫폼의 시작 검증기는 188줄에 13개 위반 규칙을 담고 있다. 현재 분석에서는 searched direct caller가 테스트에 있고 같은 패키지의 자동설정이 검증기를 직접 부르지 않는다는 점을 확인했다. 이 사실을 runtime 미실행으로 확정하려면 다른 lifecycle·framework discovery 경로도 닫아야 한다.
관계
- 시작 검증기 13개 규칙이 유일한 조립 지점에서 호출되지 않는다 이 규칙을 끌어낸 사례다.
- Bean 애너테이션이 있다는 것은 조립 증거가 아니다 같은 계열의 확인 규칙이다.