contract-testing-with-pact
Implementing consumer-driven contract testing for microservices using Pact.
安装与使用
请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。
查看来源 ↗使用指南技能说明
Contract Testing with Pact
Overview
Contract testing validates that service consumers and providers agree on request/response expectations. Pact implements consumer-driven contracts (CDC) with shareable pact files and provider verification.
Table of Contents
- What is Contract Testing
- Consumer-Driven Contracts
- Pact Fundamentals
- Pact vs Integration Testing
- Writing Consumer Tests
- Provider Verification
- Pact Broker
- CI/CD Integration
- Bi-Directional Contracts
- Async Messaging
- GraphQL
- Language Support
- Patterns and Anti-Patterns
- Breaking Change Strategy
- Monitoring Compliance
What is Contract Testing
Contract tests validate API interactions without full end-to-end setups. They prevent breaking changes by verifying expectations explicitly.
Consumer-Driven Contracts
Consumers define expectations; providers must satisfy them:
- Faster feedback for consumers
- Clear API expectations
- Reduced integration surprises
Pact Fundamentals
- Consumer tests: Generate pact files.
- Provider verification: Validate pact files.
- Pact files: JSON contracts.
- Pact Broker: Store and manage contracts.
Pact vs Integration Testing
- Pact: Validates interface compatibility.
- Integration: Validates full system behavior.
Use both for comprehensive coverage.
Writing Consumer Tests
Define interactions with matchers:
- Exact value
- Type-based matcher
- Regex matcher
Example (TypeScript):
await provider.addInteraction({
state: 'user exists',
uponReceiving: 'get user',
withRequest: { method: 'GET', path: '/users/123' },
willRespondWith: {
status: 200,
body: { id: like(123), name: like('Alice') }
}
});
Provider Verification
Provider verifies against published contracts:
- Implement state handlers
- Validate response headers/body/status
- Support pending and WIP pacts for safe changes
Pact Broker
Key features:
- Publish and version contracts
- Webhooks on new contracts
- Can-I-Deploy checks for promotion
- Visibility into compatibility
CI/CD Integration
Recommended flow:
- Consumer tests generate pact
- Publish pact to broker
- Provider verifies in CI
- Use Can-I-Deploy before release
Bi-Directional Contracts
Support for provider-defined expectations plus consumer constraints:
- Useful for GraphQL or schema-first APIs
- Prevents provider drift
Async Messaging
Pact supports message-based contracts:
- Define message payload expectations
- Verify consumer and provider handlers
GraphQL
Contract test schema and query responses:
- Use schema as a contract baseline
- Validate query response shapes
Language Support
SDKs available for:
- JavaScript/TypeScript
- Python
- Java
- Go
Patterns and Anti-Patterns
Good:
- Use flexible matchers
- Keep interactions focused
Avoid:
- Over-specifying exact values
- One contract covering multiple unrelated cases
Breaking Change Strategy
- Use pending pacts for backward-compatible changes.
- Version APIs when breaking changes are required.
- Maintain old contract until consumers migrate.
Monitoring Compliance
Track contract verification in CI and alert on failed verification runs.
Related Skills
-
16-testing/integration-testing -
09-microservices/service-design -
03-backend-api/express-rest
使用示例
查看来源仓库中的使用示例与配置说明。
查看来源 ↗来源历史
- 收录时间
- 2026-01-20
- 索引更新时间
- 2026-01-26
- Branch
- main
收录与同步日期属于本站记录。源码修改历史请查看来源仓库。
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!