Your consumer-driven contract test passes in CI, but production rejects a request because a supposedly optional field is missing. What did the contract testing actually miss?
The contract captured the shape the consumer sends, not the rules the provider enforces. Optionality lived in the schema while the real requirement lived in provider validation, and no recorded example ever omitted the field. Contract tests only verify interactions they contain, so add the negative example and verify against real code.
Answer
Short answer
A contract test verifies the interactions it contains and nothing else. If the consumer's contract never included an example that omits the field, no test ever asked the provider what happens when it is absent — so "optional" was an assumption written into a schema, never a behaviour anyone verified. The provider's validation says otherwise, and production is the first place the two met.
Was this answer helpful?
Likely follow-ups
- Where exactly would you add a test, and what would it assert?
- The provider verification runs against a stubbed service layer. What does that invalidate?
- How does a broker with can-i-deploy change this outcome?
- The field is optional unless currency is USD. How do you express that in a contract?
- When is contract testing the wrong tool and you should just run an integration test?
Related questions
- Two teams own two services that talk to each other. How do you stop one breaking the other without running both together in a shared environment?mediumAlso on contract-testing and api-testing4 min
- You own the API test suite for a service from scratch. How do you structure it, and what do you mock?hardAlso on api-testing and contract-testing8 min
- Your API suite runs on every commit against a shared database. How do you keep the tests from corrupting each other's data?hardAlso on api-testing6 min
- You need to add one field to an event and remove another, and five teams consume it. How does that roll out?hardAlso on contract-testing6 min