Pact
Consumer-driven contract testing — verify that services agree on their API contracts without end-to-end tests.
Pricing
Free / Open source
Type
Automation
Languages
JavaScript, TypeScript, Java, Python, Ruby, Go, C#
// VERDICT
Reach for Pact when independently deployed services must stay compatible and you want fast, isolated contract tests instead of brittle end-to-end runs. Skip it when you have a single service or need functional API validation.
Best for
Consumer-driven contract testing that verifies services can talk to each other, without slow end-to-end integration environments.
Avoid when
You only have one service, or you want functional API testing rather than contract verification.
CI/CD fit
Pact Broker · GitHub Actions · GitLab CI · Jenkins · Maven/Gradle/npm
Languages
JavaScript · TypeScript · Java · Python · Ruby · Go · C#
Team fit
Microservices teams · SDET teams · Teams with many independent services
Setup
Maintenance
Learning
Licence
// BEST FOR
- Verifying consumer and provider services stay compatible as they evolve
- Catching breaking API changes without full end-to-end environments
- Microservices estates where services deploy independently
- Generating contracts from consumer tests and verifying them on the provider
- Sharing and versioning contracts via a Pact Broker
- Multi-language teams (JS, Java, Python, Go, Ruby, C#)
// AVOID WHEN
- You have a single service with no inter-service contracts
- You want functional or end-to-end API testing, not contract checks
- A small team where the contract-testing overhead isn't justified
- Your services rarely change or aren't independently deployed
- The team isn't ready for the consumer-driven workflow's learning curve
- You need UI or performance testing (different tools entirely)
// QUICK START
# Example: JS consumer
npm install --save-dev @pact-foundation/pact
# write a consumer test that generates a pact, then verify it on the provider// ALTERNATIVES TO CONSIDER
| Tool | Choose it when |
|---|---|
| Spring Cloud Contract | You're a Spring/JVM shop wanting contract testing in the Spring ecosystem. |
| Karate | You want functional API tests (and Karate has contract-style features) rather than consumer-driven contracts. |
| WireMock | You want to stub a provider rather than formally verify a contract. |
// MIGRATION NOTES
Both do contract testing but differ in model - Spring Cloud Contract is provider-driven within the Spring ecosystem; Pact is consumer-driven and polyglot. Migrating means re-framing contracts around consumer expectations and adopting a Pact Broker; do it service-pair by service-pair, not all at once.
// FEATURES
- Consumer-driven contract files in JSON
- Pact Broker for sharing and versioning contracts
- PactFlow SaaS broker with extras (paid)
- Multi-language clients (JS, Java, Python, Ruby, Go, .NET)
- Webhook-driven CI verification
- Can-i-deploy checks before release
// PROS
- Catches breaking API changes without expensive E2E suites
- Language-agnostic via the broker model
- Strong CI/CD release-gate story
- Active community and governance via Pact Foundation
// CONS
- Consumer-driven model has a real learning curve
- Setup and discipline required across multiple teams
- Less useful when only one side controls both consumer and provider
// EXAMPLE QA WORKFLOW
Write consumer tests that generate a contract (pact file)
Publish contracts to a Pact Broker with version tags
Verify the provider against published contracts
Set up provider states for scenarios under test
Gate deploys with can-i-deploy on the Broker
Run verification on every service's CI pipeline
// RELATED QA.CODES RESOURCES
Cheat sheets
Glossary
Interview