Files
document-haness/docs/TechLog/tech-log-studio/seams-no-test-crosses/reference/reference-put-one-check-on-each-seam.md
T
DongHyeonkaandClaude Opus 5 f6c825e858 docs(TechLog): 글감 56개를 기록으로 쓴다
주제 13개 · Case 28 · Concept 5 · Reference 15 · Question 4 · Decision 4.
계약의 노드마다 종류가 요구하는 칸을 채우고, 본문이 있는 두 종류에는 SSOT 가 이미
그려 둔 도식 셋(value-boundaries · decision-path-404 · topic-variant-model)을
tech-log-studio/ 로 옮겨 붙였다. 새로 그린 그림은 없다.

검사 셋 전부 통과한다.
  check_body.mjs      56 편 중 본문이 있는 33 편 PASS
  check_prose.mjs     56 편 error 0
  check_evidence.mjs  --repo 포함 문제 없음
  verify-tech-log-tree.py  프로젝트 5 · error 0 · warn 0

인용한 코드블록은 전부 SSOT 에서 찾아 대조했다. check_evidence.mjs 가 본문의 각 줄과
source 앵커와 계약 제목을 다시 확인한다.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 15:29:33 +09:00

70 lines
3.6 KiB
Markdown

---
kind: REFERENCE
slug: put-one-check-on-each-seam
title: 이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다
topic: seams-no-test-crosses
topicName: 테스트가 지나지 않는 이음매
project: TechLog
status: 게시 전
verifiedOn: 2026-09-04
sourceRevision: tech-log@2026-09-02
source:
- final/document.md#§7.7
---
# 이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다
「모든 검사가 통과했는데 운영에서 깨졌다」가 다섯 번 있었다. 매번 그 이음매를 아무 테스트도 지나지 않았다. 층을 스텁으로 나눠 시험하는 구조에서는 그 나눈 자국마다 검사가 하나씩 필요하다.
## 관계
- **파드가 두 번 CrashLoopBackOff 로 들어갔다**
스프링 컨텍스트 이음매의 근거 사건이다.
- **그 SQL 은 한 번도 실행된 적이 없었다**
persistence SQL 이음매의 근거 사건이다.
- **합성 루트에 테스트가 없어 공개 사이트 전체가 오류 화면이었다**
합성 루트와 HTTP 매퍼 이음매의 근거 사건이다.
- **생성기가 계약 필드 넷을 조용히 빠뜨렸다**
생성기 이음매의 근거 사건이다.
## 목적
층을 스텁으로 나눠 시험하는 구조에서 그 나눈 자국이 검사되지 않고 남는 것을 막는다. 이 부류는 모든 검사가 초록불인 상태로 배포된다.
## 규칙
**스프링 컨텍스트를 띄우는 검사를 하나 둔다**
컴파일도 단위 테스트도 실제 DB 위의 통합 테스트도 컨텍스트를 띄우지 않을 수 있다. 스캔되는 컴포넌트의 생성자 규칙은 아키텍처 검사로 대신할 수 있다.
**persistence SQL 을 실제 DB 에서 돌리는 태스크를 둔다**
표준 `check` 가 컨테이너를 띄우지 않으면 어댑터의 SQL 은 한 줄도 실행되지 않는다. 컬럼 이름은 실행해야만 검증된다.
**계약 모양 그대로의 응답을 진짜 게이트웨이에 넣는 검사를 둔다**
화면 테스트는 정적 픽스처 어댑터를 쓰므로 계약 모양을 한 번도 통과시키지 않는다.
**실제 런타임 어댑터를 실제 응답 본문에 대고 조립하는 검사를 둔다**
게이트웨이 테스트는 실행기를 스텁으로 바꾸고 화면 테스트는 게이트웨이를 스텁으로 바꾼다. 합성 루트의 credential 결정은 둘 다 덮지 않는다.
**생성기는 모델이 만들어졌는지가 아니라 property 가 계약과 같은지로 본다**
모델은 필드가 빠져도 만들어진다. 아직 그 필드를 쓰는 코드가 없으면 컴파일도 통과한다.
## 적용 조건
스텁으로 층을 나눠 시험하는 구조. 계약이 다른 저장소에 있고 생성기를 지나 들어오거나, 컨테이너가 필요한 검사를 별도 태스크로 뺀 저장소에서 걸린다.
## 예외
그 층을 실제로 지나는 검사가 이미 있으면 더 두지 않는다.
스텁을 쓰는 테스트를 늘리는 것은 이 문제를 덮지 않는다. 스텁의 개수가 아니라 스텁이 대신한 층이 문제다.
## 예시
컨텍스트를 띄우지 않아 파드가 CrashLoopBackOff 로 들어간 것을 아키텍처 규칙으로 막았다.
삭제 경로의 SQL 이 한 번도 실행된 적이 없어서 전용 통합 테스트 태스크를 만들었다.
화면 테스트가 픽스처를 쓰므로 질문 상세의 매핑을 아무도 지나지 않았다. 계약 모양 응답을 진짜 게이트웨이에 넣으니 되돌려 보면 운영과 같은 오류로 실패한다.
생성 모델 대조를 schema 이름에서 property 로 바꿨다. 이름 대조는 필드 넷이 빠진 모델을 통과시켰다.