8.9 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 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Pact — Consumer-Driven Contract Testing 공식 설명 | official-doc | https://docs.pact.io/ | raw | high |
|
|
|
2026-05-25 | 2026-05-27 |
Pact — Consumer-Driven Contract Testing 공식 설명
Layer:
raw/official-docs/— Pact.io 공식 문서 발췌.feature-contract-verification-test-suite의 ca-tmpl 대안 (Pact CDC) 평가용 1차 자료.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-contract-verification-test-suite | "Pact CDC 는 out-of-scope" 결정의 평가 근거 — Pact 의 consumer-known subset 모델이 single-team skeleton 맥락에서 ROI 가 낮음을 검증 |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — Test Contract (§12) 의 contract level 대안 평가
컨텍스트 / 왜 저장했는지
feature-contract-verification-test-suite branch 는 ca-tmpl 결정으로 JSON snapshot test (approvaltests) + OpenAPI drift 를 채택하고 Pact CDC 는 out-of-scope 로 선언했다. 그 결정이 정당했는지 확인하려면 Pact 가 무엇이고, "boundary 외부 통합 시만 도입" 조건이 공식 가이드와 일치하는지 원문 근거가 필요하다. 또한 향후 외부 consumer 가 등장했을 때 채택 임계점을 판단하기 위함이다.
출처 / Source
- 원본 URL: https://docs.pact.io/
- 아카이브 URL: (미수집)
- 저자 / 조직: Pact Foundation
- 발행일: 지속적으로 갱신 (latest fetched 2026-05)
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Pact 정의] "Pact is a code-first tool for testing HTTP and message integrations using
contract tests."
[§Contract generation] "The contract is generated during the execution of the automated consumer tests."
[§Consumer/Provider terminology] "A contract is between a consumer (for example, a client that wants to receive some data) and a provider (for example, an API on a server that provides the data the client needs)."
[§Consumer-driven advantage] "Only parts of the communication that are actually used by the consumer(s) get tested."
[§Provider contract testing 한계] "This type of contract testing helps avoid integration failures by ensuring the provider code and documentation are in sync with each other. On its own, however, it does not provide any test based assurance that the consumers are calling the provider in the correct manner, or that the provider can meet all its consumers' expectations, and hence, it is not as effective in preventing integration bugs."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| PACT-OFFICIAL-C1 | Pact 는 code-first tool 로 HTTP 와 message 통합을 contract test 로 검증 | [§Pact 정의] "Pact is a code-first tool for testing HTTP and message integrations using contract tests." |
official-vendor-doc |
HTTP/message 통합 contract test 도구 선택 | UI/binary protocol 같은 다른 통합 형식 보장 아님 |
| PACT-OFFICIAL-C2 | contract 는 consumer 측 자동화 테스트 실행 중 생성됨 (consumer-driven 핵심) | [§Contract generation] "The contract is generated during the execution of the automated consumer tests." | official-vendor-doc |
CDC 워크플로의 contract 생성 시점 | provider 가 contract 를 먼저 정의하는 모드 (provider-driven) 는 본 인용에 없음 |
| PACT-OFFICIAL-C3 | contract 는 consumer (데이터 요청 client) 와 provider (데이터 공급 API) 사이의 합의 | [§Consumer/Provider terminology] "A contract is between a consumer (for example, a client that wants to receive some data) and a provider (for example, an API on a server that provides the data the client needs)." | official-vendor-doc |
Pact terminology 의 정확한 정의 | consumer/provider 가 반드시 별도 팀이어야 한다는 뜻은 아님 — 정의는 application role 기반 |
| PACT-OFFICIAL-C4 | consumer 가 실제로 사용하는 communication 부분만 테스트됨 (full schema 가 아님) | [§Consumer-driven advantage] "Only parts of the communication that are actually used by the consumer(s) get tested." | official-vendor-doc |
Pact 의 검증 범위 (subset, not full schema) | Pact 가 full-schema 검증을 의도적으로 배제한다는 뜻은 아님 — 다른 도구와 결합 가능 |
| PACT-OFFICIAL-C5 | provider contract testing 단독 (OpenAPI 같은 spec 검증) 으로는 consumer 가 provider 를 올바르게 호출하는지 또는 provider 가 모든 consumer 의 expectation 을 충족하는지 test-based assurance 를 제공하지 않으며, integration bug 예방에 덜 효과적 | [§Provider contract testing 한계] "This type of contract testing helps avoid integration failures by ensuring the provider code and documentation are in sync with each other. On its own, however, it does not provide any test based assurance that the consumers are calling the provider in the correct manner, or that the provider can meet all its consumers' expectations, and hence, it is not as effective in preventing integration bugs." | official-vendor-doc |
provider-only contract test (OpenAPI drift 등) 의 한계 | provider-only 가 모든 시나리오에서 무용하다는 뜻은 아님 — single-consumer 면 subset = full schema |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
PACT-OFFICIAL-C1: Pact 의 self-definition (HTTP/message contract test 도구)PACT-OFFICIAL-C2: contract 가 consumer 측 test 실행 중 생성된다는 메커니즘PACT-OFFICIAL-C3: consumer/provider 의 공식 정의PACT-OFFICIAL-C4: 검증 범위가 consumer-used subset 에 국한PACT-OFFICIAL-C5: provider-only contract test (OpenAPI drift 단독) 의 한계 (multi-consumer 맥락에서)
- 이 자료가 증명하지 않는 것:
- "ApprovalTests snapshot 대비 우월" 또는 "열위" 의 직접 비교 — homepage 는 비교 없음
- "internal-only skeleton 에서 Pact 도입 ROI 가 낮다" — 본 자료에 없음, ca-tmpl 의 별도 분석
- Pact Broker 인프라 비용 — homepage 본 발췌에 없음 (별도 페이지)
- "외부 partner consumer 등장이 도입 임계점" — 본 자료에 없는 ca-tmpl 의 운영 판단
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 "boundary 외부 통합 시만 도입" 임계점 정의 — 본 자료는 임계점 정량화 안 함
- Pact Broker / versioning workflow 의 실제 운영 비용 (skeleton 단계 over-engineering 여부)
- Pact 의 message contract 가 ca-tmpl 의 비동기 통신 (Kafka 등) 에 적합한지 — 별도 페이지 필요
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- Pact 의 강점은 consumer 가 실제로 사용하는 interaction 만 검증한다는 것 (
PACT-OFFICIAL-C4가 직접 지지). snapshot 기반 OpenAPI drift 는 provider-side full schema 를 보호하는 반면, Pact 는 consumer-known subset 만 보호. - 따라서 internal-only skeleton 에서는 consumer-known subset 이 곧 전체 schema 이므로 Pact 도입 이득이 낮음 → ca-tmpl out-of-scope 결정과 일치 (단 본 자료 직접 증명 아님 — 해석).
PACT-OFFICIAL-C5는 multi-consumer 맥락에서 provider-only (OpenAPI drift 단독) 의 한계를 명시 — ca-tmpl 이 외부 partner consumer 등장 시 Pact 재검토할 근거가 됨.- 외부 partner 또는 별도 팀이 consumer 가 되는 시점이 Pact 도입 임계점 — ca-tmpl 의 별도 정책.
- Pact Broker (별도 인프라) 와 versioning workflow 가 필요 — skeleton 단계에서 over-engineering (본 인용 범위 밖, 다른 페이지 확인 필요).
Related / 관련
- 같은 주제 다른 official-doc / 자료:
- raw/official-docs/verification-spring-cloud-contract-official — Spring 생태계 CDC 대안
- raw/official-docs/verification-approvaltests-snapshot-official — ca-tmpl 채택안 (snapshot)
- raw/official-docs/test-taxonomy-practical-pyramid-fowler — CDC workflow 일반론
- raw/official-docs/test-taxonomy-testcontainers-official — integration level 와의 역할 분리
- 인용하는 branch:
- canonical contract 섹션:
- raw/project-notes/ca-skeleton-operational-contract (Test Contract §12)
- 대안 그룹: Group G-G — Skeleton Governance (verification)
- 본 source 의 위치: 대안 1 — Pact consumer-driven contract (ca-tmpl out-of-scope 사유 근거)
- 인용하는 wiki: (미작성)