DongHyeonkaandClaude Opus 5
193da20d09
게시된 Reference 15편이 전부 규칙을 `### N. 제목` 으로 쓰고 적용 조건·예외·예시를 항목으로 쓴다. 내 15편은 규칙을 `**굵게**` 로, 나머지 셋을 문단으로 쓰고 있었다 — Studio 의 rules[]·applyWhen[]·exceptions[]·examples[] 는 배열이라 문단으로 두면 항목이 하나로 접힌다. 규칙 68개를 `### N. 제목` 으로 바꿨다 (편당 3~7개, 게시된 것은 4~10개) 적용 조건·예외·예시를 항목으로 갈랐다. 한 항목뿐이던 아홉 편은 조건을 나눠 적었다 주제 6 은 본문을 다시 썼다 — location = 이 정확히 일치하는 경로만 잡아 27개가 얼어붙은 구조, 여덟 곳이 우는 시점을 셋으로 가른 표, digest 를 다시 계산할 때 옛 값을 먼저 재현하는 이유. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.9 KiB
kind, slug, title, topic, topicName, project, status, verifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | verifiedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| REFERENCE | put-one-check-on-each-seam | 이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다 | seams-no-test-crosses | 테스트가 지나지 않는 이음매 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
이음매마다 그 이음매를 실제로 지나는 검사를 하나씩 둔다
「모든 검사가 통과했는데 운영에서 깨졌다」가 다섯 번 있었다. 매번 그 이음매를 아무 테스트도 지나지 않았다. 층을 스텁으로 나눠 시험하는 구조에서는 그 나눈 자국마다 검사가 하나씩 필요하다.
관계
- 파드가 두 번 CrashLoopBackOff 로 들어갔다 스프링 컨텍스트 이음매의 근거 사건이다.
- 그 SQL 은 한 번도 실행된 적이 없었다 persistence SQL 이음매의 근거 사건이다.
- 합성 루트에 테스트가 없어 공개 사이트 전체가 오류 화면이었다 합성 루트와 HTTP 매퍼 이음매의 근거 사건이다.
- 생성기가 계약 필드 넷을 조용히 빠뜨렸다 생성기 이음매의 근거 사건이다.
목적
층을 스텁으로 나눠 시험하는 구조에서 그 나눈 자국이 검사되지 않고 남는 것을 막는다.
이 부류는 모든 검사가 초록불인 상태로 배포된다. 각 층의 검사는 자기 층을 정확히 보고 통과하며, 통과하지 않은 것은 층과 층 사이다.
규칙
1. 스프링 컨텍스트를 띄우는 검사를 하나 둔다
컴파일도 단위 테스트도, 실제 데이터베이스를 쓰는 통합 테스트도 컨텍스트를 띄우지 않을 수 있다. 컨테이너가 필요해서 통합 테스트인 것과 컨텍스트를 띄우는 것은 다르다. 스캔되는 컴포넌트의 생성자 규칙처럼 정적으로 셀 수 있는 것은 아키텍처 검사로 대신할 수 있고, 그 편이 빌드 시간을 늘리지 않는다.
2. persistence SQL 을 실제 데이터베이스에서 돌리는 태스크를 둔다
표준 검사가 컨테이너를 띄우지 않으면 어댑터의 SQL 은 한 줄도 실행되지 않는다. 컴파일은 문자열 안을 보지 않고 단위 테스트는 어댑터를 스텁으로 바꾸므로, 컬럼 이름은 실행해야만 검증된다.
3. 계약 모양 그대로의 응답을 진짜 게이트웨이에 넣는 검사를 둔다
화면 테스트는 정적 픽스처 어댑터를 쓰므로 계약 모양을 한 번도 통과시키지 않는다. 픽스처를 게이트웨이가 읽는 모양으로 만들면 그 테스트는 늘 통과한다.
4. 실제 런타임 어댑터를 실제 응답 본문에 대고 조립하는 검사를 둔다
게이트웨이 테스트는 실행기를 스텁으로 바꾸고 화면 테스트는 게이트웨이를 스텁으로 바꾼다. 합성 루트에서 credential 을 정하는 코드는 둘 다 덮지 않는다.
5. 생성기는 모델이 만들어졌는지가 아니라 property 가 계약과 같은지로 본다
모델은 필드가 빠져도 만들어진다. 아직 그 필드를 쓰는 코드가 없으면 컴파일도 통과한다.
6. 전용 태스크로 뺐으면 그것을 돌리는 것이 사람 몫이라는 것도 적는다
컨테이너를 띄우는 검사를 표준 검사에 넣으면 모든 빌드가 느려진다. 빼는 것은 되지만, 뺀 뒤에 그 태스크가 돌지 않으면 검사가 없는 것과 같다.
적용 조건
-
스텁으로 층을 나눠 시험하는 구조. 계약이 다른 저장소에 있고 생성기를 지나 들어오거나, 컨테이너가 필요한 검사를 별도 태스크로 뺀 저장소에서 걸린다.
-
「모든 검사가 통과했는데 운영에서 깨졌다」가 나오면 무엇이 깨졌는지보다 어느 이음매를 아무 검사도 지나지 않았는지를 먼저 센다.
예외
-
그 층을 실제로 지나는 검사가 이미 있으면 더 두지 않는다.
-
스텁을 쓰는 테스트를 늘리는 것은 이 문제를 덮지 않는다. 스텁의 개수가 아니라 어느 층을 대신했는지가 기준이다.
-
정적으로 셀 수 있는 규칙은 컨텍스트를 띄우지 않고도 걸린다. 그때는 무거운 검사를 새로 두지 않는다.
예시
-
컨텍스트를 띄우지 않아 파드가 두 번 CrashLoopBackOff 로 들어갔다. 실제 PostgreSQL 위에서 도는 통합 테스트 26개도 통과한 상태였다.
-
삭제 경로의 SQL 이 한 번도 실행된 적이 없어서 전용 통합 테스트 태스크를 만들었다.
-
화면 테스트가 픽스처를 쓰므로 질문 상세의 매핑을 아무도 지나지 않았다. 계약 모양 응답을 진짜 게이트웨이에 넣으니 되돌려 보면 운영과 같은 오류로 실패한다.
-
생성 모델 대조를 schema 이름에서 property 로 바꿨다. 이름 대조는 필드 넷이 빠진 모델을 통과시켰다.