contract-testing
Concept of the skill
What it is: Contract testing verifies that consumers and providers remain compatible by turning interface expectations into executable contracts that providers replay and publish as verification results.
Mental model: A consumer records the smallest meaningful promise it relies on, the provider proves that promise still holds, and a broker or CI gate answers whether the relevant versions can deploy together.
Why it exists: It protects service boundaries without relying on slow, brittle cross-service end-to-end suites or treating a schema as proof that real consumer behavior is safe.
What it is NOT: It is not a replacement for provider integration tests, user-journey end-to-end tests, property-based testing, or API design governance.
Adjacent concepts: API design, system interface contracts, event contract design, integration test design, test doubles, deploy gates.
One-line analogy: Contract testing is a lease agreement for an interface: each side can change internally, but shared obligations must still be honored.
Common misconception: Pact-style tests are not valuable because they mock providers; the provider replay and published verification result are the part that turns mocks into deploy confidence.