How Pact contract testing works
PactFlow allows developers and their teams to use contract testing with Pact and other contract types (such as OpenAPI).
The problem with integration tests
Why not use isolated tests?
How Pact helps - the consumer side
How Pact helps - the provider side
How Pact helps
Sharing the contracts and CI/CD integration
Sharing the contracts and CI/CD integration
Before we deploy an application to production, we need to be sure it works correctly with the other applications with which it integrates. To do this, traditionally we run integration tests using "live", deployed applications.
Integration tests
- ✅ give us confidence to release
but
- ❌ introduce dependencies
- ❌ give slow feedback
- ❌ break easily
- ❌ require lots of maintenance
Replay animation
By testing each side of an integration point using a simulated version of the other application, we get two sets of tests which
- ✅ run independently
- ✅ give fast feedback
- ✅ are stable
- ✅ are easy to maintain
but
- ❌ do not give us confidence to release.
This is because there is nothing to ensure that the simulated applications behave the same way as the real ones.
Replay animation
Pact solves the problem of keeping the two sets of tests in sync by use of a "contract", also known as a "pact".
During the consumer tests, each request made to a Pact mock provider is recorded into the contract file, along with its expected response.
Replay animation
A Pact simulated consumer then replays each request against the real provider, and compares the actual and expected responses. If they match, we have verified that the simulated applications behave the same way as the real applications. This means the two real applications should communicate correctly when they interact in real life.
Replay animation
Next
