9.5 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Martin Fowler / Ham Vocke — The Practical Test Pyramid | personal-blog | https://martinfowler.com/articles/practical-test-pyramid.html | raw | high |
|
|
|
2026-05-25 | 2026-05-27 |
Martin Fowler / Ham Vocke — The Practical Test Pyramid
Layer:
raw/official-docs/— martinfowler.com에 호스팅된 Ham Vocke의 long-form article.source_type분류상personal-blog(Martin Fowler 개인 사이트 게재). ca-tmpl 6-level taxonomy 와 classic 3-layer pyramid 비교의 1차 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-test-taxonomy-fixture-contract | classic pyramid (unit/service/UI) 의 권위 있는 정의 — ca-tmpl 6-level taxonomy 가 그 확장임을 비교하기 위한 baseline |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — Test Contract (§12) 설계의 정합성 검증
컨텍스트 / 왜 저장했는지
ca-tmpl의 6-level taxonomy는 classic 3-layer pyramid(unit/service/UI)의 확장이다. Fowler/Vocke의 정의를 원문으로 보존해 두면 architecture/contract layer를 왜 별도로 두는지 비교가 쉽다. 또한 "integration test" 용어가 팀마다 달라 혼란을 만드는 문제도 원문이 명시.
출처 / Source
- 원본 URL: https://martinfowler.com/articles/practical-test-pyramid.html
- 아카이브 URL: (미수집)
- 저자 / 조직: Ham Vocke (게재: Martin Fowler 사이트)
- 발행일: 2018-02-26 (이후 일부 업데이트)
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§The Test Pyramid] "Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end."
[§Integration Tests — Narrow] "Narrow integration tests live at the boundary of your service...testing one integration point at a time by replacing separate services and databases with test doubles."
[§Integration Tests — Broad] "Integrating with a service over the network is a typical characteristic of a broad integration test and makes your tests slower and usually harder to write."
[§Contract Tests / CDC] "The consuming team writes automated tests with all consumer expectations...The providing team runs the CDC tests continuously and keeps them green."
[§End-to-End Tests] "Due to their high maintenance cost you should aim to reduce the number of end-to-end tests to a bare minimum."
[§The Confusion About Testing Terminology] "The important takeaway is that you should find terms that work for you and your team. Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| TPP-FOWLER-C1 | 권장 분포는 unit 다수 + 중간 입자도 일부 + e2e 매우 소수 | [§The Test Pyramid] "Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests..." | engineering-blog |
일반 application/service test strategy | 정확한 비율 (예: 70/20/10) 을 규정하지 않음 — "lots/some/very few" 만 |
| TPP-FOWLER-C2 | narrow integration test 는 서비스 boundary 에서 1개 integration point 씩, 외부 서비스/DB 를 test double 로 대체 | [§Integration Tests] "Narrow integration tests live at the boundary of your service...testing one integration point at a time by replacing separate services and databases with test doubles." | engineering-blog |
service-boundary integration test 정의 | "test double 만이 narrow 의 정의" 라는 뜻은 아님 — Testcontainers 같은 real-dep 도 narrow scope 로 사용 가능 (본 인용 범위 밖) |
| TPP-FOWLER-C3 | network 너머 service 와 통합하는 것이 broad integration test 의 전형적 특성이며 slower/harder to write | [§Integration Tests] "Integrating with a service over the network is a typical characteristic of a broad integration test and makes your tests slower and usually harder to write." | engineering-blog |
broad integration test 의 비용/특성 분류 | network call 만 있으면 무조건 broad 라는 일반화는 아님 — local Testcontainers 의 경우 본 인용은 직접 적용 안 됨 |
| TPP-FOWLER-C4 | CDC 에서 consumer 팀이 expectations 를 자동화 테스트로 작성하고 provider 팀이 그 테스트를 계속 green 으로 유지 | [§Contract Tests] "The consuming team writes automated tests with all consumer expectations...The providing team runs the CDC tests continuously and keeps them green." | engineering-blog |
CDC 워크플로의 책임 분배 | Pact/Spring Cloud Contract 등 특정 도구 채택을 의무화하지 않음 — workflow 만 |
| TPP-FOWLER-C5 | e2e test 는 유지비가 높으므로 최소한으로 줄이는 것을 목표로 해야 함 | [§End-to-End Tests] "Due to their high maintenance cost you should aim to reduce the number of end-to-end tests to a bare minimum." | engineering-blog |
e2e test 수량 정책 | 0개로 두라는 뜻은 아님 — "bare minimum" |
| TPP-FOWLER-C6 | 테스트 용어는 팀마다 다르므로 팀 내에서 합의된 용어 + 각 type 의 scope 합의가 중요 | [§The Confusion About Testing Terminology] "...you should find terms that work for you and your team. Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test." | engineering-blog |
팀 단위 test taxonomy 합의 정책 | 특정 taxonomy (3-layer vs 6-layer) 가 우월하다는 주장 아님 |
Strength 정당화
본 자료는 권위 있는 industry reference 이지만 source_type: personal-blog (Martin Fowler 개인 사이트의 게스트 article) 으로 분류되어 있으므로 strength 는 engineering-blog 가 정확함. official-standard/official-vendor-doc/official-reference 모두 해당 없음.
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
TPP-FOWLER-C1: 권장 테스트 분포의 정성적 모양 (피라미드)TPP-FOWLER-C2: narrow integration test 의 정의 (서비스 boundary, 1개 integration point, test double 사용)TPP-FOWLER-C3: broad integration test 의 비용 특성 (network 통합 = slower/harder)TPP-FOWLER-C4: CDC workflow 의 책임 분배 (consumer 작성, provider 유지)TPP-FOWLER-C5: e2e test 최소화 원칙TPP-FOWLER-C6: 팀 단위 용어 합의 원칙
- 이 자료가 증명하지 않는 것:
- ca-tmpl 의 "architecture test 를 별도 level 로 두라" — Fowler/Vocke 의 분류에 없음
- Testcontainers 가 narrow integration 의 정의에 부합한다는 단정 — 본 article 은 "test double" 표현 사용, real-container 는 별도 판단 필요
- "5분 budget" 같은 정량 기준 — 본 article 은 빠르게 = "fast" 로만 표현
- Pact/ApprovalTests/Spring Cloud Contract 같은 특정 도구 선택의 우열
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 6-level 분류가 Fowler "팀 합의" 원칙과 정합하는지 —
feature-test-taxonomy-fixture-contract의 Test Level Matrix 정의 검토 - "narrow integration with Testcontainers" 가 본 article 의 narrow 정의에 들어가는지 — 본 자료만으로는 부족, Testcontainers 공식 자료 (
test-taxonomy-testcontainers-official.md) 와 cross-check
- ca-tmpl 의 6-level 분류가 Fowler "팀 합의" 원칙과 정합하는지 —
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- Fowler/Vocke 은 "narrow vs broad integration" 을 구분. 본 skeleton 의 integration = Testcontainers + real provider 는 narrow integration 의 scope (1개 integration point) 에 맞지만 "test double 로 대체" 부분과는 다른 선택 — real container 사용. 본 자료는 이 선택을 직접 정당화하지 않음 (Testcontainers 공식 자료 별도 필요).
- ca-tmpl 이 architecture test 를 별도 level 로 둔 점은 classic pyramid 에 없는 추가물. ArchUnit/fitness function 흐름의 영향 — 본 자료 범위 밖.
- "consistency within your team" 원칙 = 본 skeleton 의 Test Level Matrix 가 그 합의를 명문화한 것 (
TPP-FOWLER-C6으로 지지됨).
Related / 관련
- 같은 주제 다른 official-doc / 자료:
- raw/official-docs/test-taxonomy-testcontainers-official — Testcontainers 공식 입장 (real services in Docker)
- raw/official-docs/verification-pact-cdc-official — CDC 의 공식 도구 (Pact)
- raw/official-docs/verification-spring-cloud-contract-official — Spring 생태계 CDC 대안
- raw/official-docs/verification-approvaltests-snapshot-official — snapshot 기반 verification 대안
- 인용하는 branch:
- canonical contract 섹션:
- raw/project-notes/ca-skeleton-operational-contract (Test Contract §12)
- 대안 그룹: Group G-G — Skeleton Governance (test taxonomy)
- 본 source 의 위치: 대안 1 — Classic test pyramid (Fowler/Cohn)
- 인용하는 wiki: (미작성)