Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.5 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed

title

source_type

url

archive_url

status

confidence

Kent C. Dodds — Write tests. Not too many. Mostly integration. (Testing Trophy)

Layer: raw/company-tech-blogs/ (분류: 실제 source_type 은 personal-blog. 디렉토리 정정 후보 — 본 migration 에서는 자동 mv 금지, 위치 유지). Kent Dodds 개인 블로그 발췌. ca-tmpl 의 6-level test taxonomy 결정에 대한 대안 모델 (Testing Trophy) 평가용.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-test-taxonomy-fixture-contract	6-level taxonomy (unit/contract/architecture/slice/integration/smoke) vs Testing Trophy (mostly integration) 대안 비교 근거. ca-tmpl 이 trophy 철학에서 갈리는 지점 명문화
raw/project-notes/ca-skeleton-operational-contract	§12. Test Contract 의 외부 대안 사례 — frontend 출신 trophy 모델의 백엔드 적용 한계 명시

컨텍스트 / 왜 저장했는지

feature-test-taxonomy-fixture-contract 의 ca-tmpl 은 6-level taxonomy (unit / contract / architecture / slice / integration / smoke) 를 채택. 이는 전통적 test pyramid 의 변형이지만 contract/architecture 가 추가된 형태. Testing Trophy 는 "integration > unit" 을 주장하는 대안 모델이므로, 본 skeleton 의 결정이 trophy 철학과 어디서 갈리는지 명문화하기 위해 보관.

출처 / Source

원본 URL: https://kentcdodds.com/blog/write-tests
아카이브 URL: (미수집)
저자 / 조직: Kent C. Dodds (개인)
발행일: 2018 (이후 업데이트)
마지막 확인일: 2026-05-27

핵심 인용 / Key quotes (verbatim)

[§Core principle] "Write tests. Not too many. Mostly integration."

[§Testing Trophy 정의] "The Testing Trophy 🏆 A general guide for the return on investment 🤑 of the different forms of testing with regards to testing JavaScript applications."

[§Integration sweet spot] "Integration tests strike a great balance on the trade-offs between confidence and speed/expense."

[§Coverage diminishing returns] "you get diminishing returns on your tests as the coverage increases much beyond 70%"

[§Unit vs Integration confidence] "as you move up the pyramid, the confidence quotient of each form of testing increases. You get more bang for your buck."

[§Shallow rendering 한계] "It doesn't matter if your component <A /> renders component <B /> with props c and d if component <B /> actually breaks if prop e is not supplied."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
TROPHY-C1	Kent Dodds 의 핵심 권고는 "Write tests. Not too many. Mostly integration." — 적정량 + integration 중심	[§Core principle] "Write tests. Not too many. Mostly integration."	`engineering-blog`	JavaScript / frontend 애플리케이션 테스트 전략	이 권고가 백엔드 시스템에도 동일하게 적용된다는 일반화는 아님 — 원문이 frontend 맥락
TROPHY-C2	Testing Trophy 는 "JavaScript 애플리케이션의 테스트 형태별 ROI (return on investment) 가이드" 로 정의됨	[§Testing Trophy 정의] "The Testing Trophy 🏆 A general guide for the return on investment 🤑 of the different forms of testing with regards to testing JavaScript applications."	`engineering-blog`	JavaScript 애플리케이션의 ROI 기반 테스트 전략	Trophy 가 모든 언어/도메인 (백엔드, 임베디드 등) 의 ROI 표준이라는 뜻은 아님
TROPHY-C3	Integration test 는 confidence vs speed/expense trade-off 의 균형점 이라고 주장	[§Integration sweet spot] "Integration tests strike a great balance on the trade-offs between confidence and speed/expense."	`engineering-blog`	integration test 의 ROI 평가	정량 측정 데이터 없음 — 저자의 주장. unit/E2E 와의 비교 수치 부재
TROPHY-C4	70% 커버리지 이상에서는 추가 테스트의 diminishing returns (한계 효용 감소) 가 발생한다고 주장	[§Coverage diminishing returns] "you get diminishing returns on your tests as the coverage increases much beyond 70%"	`engineering-blog`	코드 커버리지 목표치 설정	70% 가 객관적 최적 임계값이라는 증명 아님 — 저자의 경험적 권고. 도메인/리스크에 따라 다를 수 있음
TROPHY-C5	테스트 피라미드 위로 올라갈수록 confidence quotient 증가 ("more bang for your buck") — unit < integration < E2E 순으로 신뢰도	[§Unit vs Integration confidence] "as you move up the pyramid, the confidence quotient of each form of testing increases. You get more bang for your buck."	`engineering-blog`	테스트 layer 별 신뢰도 평가	"비용 대비 신뢰도" 의 정량 비율은 없음. unit 의 속도 우위는 본 인용에서 인정하지 않은 게 아니라 별도 트레이드오프
TROPHY-C6	shallow rendering 은 컴포넌트 간 통합 누락을 잡지 못한다는 구체 예시: `<A />` 가 `<B />` 를 props `c,d` 로 렌더해도 `<B />` 가 prop `e` 없을 때 깨지면 의미 없음	[§Shallow rendering 한계] "It doesn't matter if your component `<A />` renders component `<B />` with props `c` and `d` if component `<B />` actually breaks if prop `e` is not supplied."	`engineering-blog`	React 컴포넌트 테스트의 shallow rendering 한계	백엔드 mock-heavy unit test 의 한계로 일반화하려면 별도 논증 필요 — 본 예시는 React 컴포넌트 특화

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- TROPHY-C1 ~ C6: Kent Dodds 의 Testing Trophy 권고 (JS/frontend 맥락) — integration 중심, 70% 커버리지 한계 효용, shallow rendering 한계 예시
이 자료가 증명하지 않는 것:
- Testing Trophy 가 백엔드 시스템의 best practice 라는 명제 — 원문 명시적으로 "JavaScript applications" 맥락
- 70% 가 객관적/실증적 최적 커버리지라는 명제 — 저자 경험 기반
- unit test 가 일반적으로 불필요하다는 명제 — 원문은 "mostly integration" 이지 "no unit"
- ca-tmpl 의 6-level taxonomy 가 trophy 보다 우월/열등하다는 명제
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 contract test layer 가 trophy 의 integration 역할 일부를 대체하는지의 실증 (CI 시간 / 발견 버그 비율)
- 백엔드 도메인에서 "mostly integration" 채택 시 Testcontainers 사용 부담 (ca-tmpl 의 5분 CI budget 과의 충돌)
- 70% 커버리지 목표가 ca-tmpl 의 운영 contract 검증에 적정한지 (인프라 코드 별도 고려)

메모 / Notes

검증되지 않은 내 해석은 wiki source-summary 단계에서만.

Trophy 는 frontend 맥락 에서 출발했고 "shallow rendering 회피" 가 핵심 논거.
백엔드 skeleton 에서는 contract test 가 trophy 의 integration 역할 일부를 대체 한다 (해석, 미검증). 즉 envelope/log/env/error 같은 운영 계약은 unit 이 아니라 contract level 에서 보호.
따라서 본 skeleton 의 6-level 중 contract layer 는 trophy 의 integration boundary 일부를 빠르게 (no container) 잡는 zone 으로 볼 수 있음 (해석).
차이점 (해석): trophy 는 "mostly integration", 본 skeleton 은 "mostly unit + contract + architecture" + integration 은 별도 gate.
이 차이는 5분 CI budget + Testcontainers cost 때문이고, contract test 에 Testcontainers 를 금지한 결정과 직결 (별도 결정 노트 검증 필요).
출처 분류: source_type: personal-blog — 참고 자료. 공식 best practice 로 격상 금지 (CLAUDE.md §5).

같은 주제 다른 raw:
- (test pyramid 원본 출처 — Mike Cohn 의 "Succeeding with Agile" 별도 raw 추가 후보)
인용하는 branch:
- raw/branch-notes/feature-test-taxonomy-fixture-contract (대안 2)
인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (Group G-G — Skeleton Governance / test taxonomy)
인용한 wiki 요약: (미작성)

8.5 KiB Raw Blame History