- analysis/·source-index·state.json 을 final/document.md 제2부·제3부로 접었다. SSOT 는 하나다 - 파일럿 — commit-ambiguity-as-a-result 를 새 기준으로 재선별. 후보 14 → 글감 5 (PROMOTE 5 · MERGE_INTO 3 · KEEP_IN_SSOT 4 · 보류 2). 기록 5건을 다시 썼고 그림 1개를 techviz 로 만들었다 - 재선별이 잡은 것: 제1부 §6.2·§11.1 이 자기 §13.2 와 어긋나 있었다(레인을 안 돌렸다 vs 돌렸다) — 정정. 이미 답이 나와 있던 Question 을 HEAD 재실행 질문으로 다시 세웠다. Concept 이 인용한 코드가 SSOT 에 없어 뺐다 - candidateScope·sourceRepository 기록. 나머지 43개 주제는 재선별 대기(PENDING 905) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.6 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, evidenceCapturedOn, assets, evidence, source
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | evidenceCapturedOn | assets | evidence | source | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | analysis-finding-a06-f028 | 소비자가 없는 fixture 셋 | multitenancy-isolation | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | case:analysis-finding-a06-f028 | 2026-09-01 |
|
|
|
소비자가 없는 fixture 셋
테스트킷의 세 타입이 테스트와 테스트킷 양쪽 모두에서 소비자가 0 이다. 그중 하나는 서버를 통과하는 왕복 계약을 실행하도록 만들어진 것이고, 그 계약은 열거된 계약 목록에 들어 있다.
관계
- 계약 테스트는 어댑터가 실제로 돌리는 statement를 실행해야 한다 왕복 계약이 존재하는 이유다.
- release gate가 실제로 차단하는 것은 hermetic test 3개이고 이 리프용 CI workflow는 없다 같은 리프의 검증 지형을 다룬 사례다.
- Bean 애너테이션이 있다는 것은 조립 증거가 아니다 타입의 존재와 사용을 나눠 세는 규칙이다.
문제
테스트킷은 계약을 실행할 도구를 담는다. 그 도구들이 실제로 쓰이는지 확인이 필요하다.
결론
소비자 계수에서 양쪽 모두 0 인 타입이 셋이다.
로컬 컨테이너 타입은 검색과 벡터 계약의 빠른 피드백용이다. 관련 보고 타입은 테스트 한 곳에서 쓰이지만 실제 컨테이너를 띄우는 곳은 없다.
청크 이동 제어기는 트래픽 중 청크 이동을 재현하는 유일한 장치다. 재조정 중 프로덕션 요청이 들어오는 상황을 만든다.
왕복 계약은 자바에서 BSON 으로 서버를 거쳐 원시 BSON 으로 다시 자바로 돌아오는 왕복을 검증한다. javadoc 이 그 이유를 적는다. 왕복의 절반은 아무것도 증명하지 않으며 가운데의 원시 BSON 만이 그것을 보여 준다.
셋째가 가장 무겁다.
계약 열거형이 골든 BSON 을 열거된 계약으로 두는데, 그 계약을 실행하도록 만들어진 타입에 호출자가 없다.
BSON 스냅숏과 그 단언 도우미는 쓰인다. 그래서 정규형 단언은 존재하지만 서버를 통과하는 왕복은 돌지 않는다.
그리고 그 차이가 정확히 이 클래스가 존재하는 이유다.
검증 환경
OpenJDK : 21.0.12 확인 방식 : 테스트킷 타입별 소비자 계수 소스 수정 : x
재현 조건
원문은 final/evidence/raw/138 계열에 있다.
- 테스트킷의 타입 목록을 만든다.
- 각 타입의 테스트와 테스트킷 소비자를 센다.
- 소비자가 0 인 타입의 javadoc 을 읽는다.
- 왕복 계약이 계약 열거형에 있는지 확인한다.
- 정규형 단언 도우미가 쓰이는지 확인한다.
본문
138-... §8.1의 소비자 계수에서 test·testkit 양쪽 모두 0인 타입이 셋이다.
| 타입 | 무엇을 위한 것인가 |
|---|---|
MongoAtlasLocalContainer |
Atlas Local 컨테이너 — search·vector 계약의 빠른 피드백용. MongoAtlasCapabilityContractSuite(report 타입)는 test 1곳에서 쓰이지만, 실제 컨테이너를 띄우는 곳은 없다 |
MongoChunkMigrationController |
트래픽 중 청크 이동 — "production hits during a rebalance"를 재현하는 유일한 장치 |
MongoRoundTripContract |
Java → BSON → 서버 → raw BSON → Java 왕복. javadoc: "Half a round trip proves nothing… only the raw BSON in the middle shows it" |
test 와 testkit 양쪽에서 0 인 타입
:::evidence key="analysis-finding-a06-f028" alt="분석 문서 final/document.md#a06 에서 이 기록의 근거 절을 그대로 잘라낸 15줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md#a06 발췌 — 15줄" zoom="true" :::
셋째가 가장 무겁다
MongoReleaseContract의 형제인 MongoReplicaSetContract는 GOLDEN_BSON을 열거된 계약으로 두는데, 그 계약을 실행하도록 만들어진 타입에 호출자가 없다. MongoBsonSnapshot·MongoBsonSnapshotAssert는 쓰이므로 정규형 단언은 존재하지만 서버를 통과하는 왕복은 돌지 않는다 — 그리고 그 차이가 정확히 이 클래스가 존재하는 이유다. P3.
확인하지 못한 것
왕복 계약을 실제로 실행해 원시 BSON 이 기대와 다른지 확인하지 않았다.