Contract Testing (Consumer-Driven) (EN)

Contract tests reduce integration risk by ensuring that providers and consumers agree on the API contract.

They sit between unit tests and full integration tests:

• Unit tests: fast, isolated
• Integration tests: validate real composition
• Contract tests: validate compatibility across team/service boundaries

1) What contract testing actually guarantees

A contract test typically guarantees:

• required fields exist
• field types and formats are stable
• response codes and error shapes are stable
• backward compatibility rules are respected

It does not guarantee:

• provider performance
• end-to-end business correctness
• cross-service workflows

2) When to use contract tests

High ROI when:

• multiple teams deploy independently
• you maintain public APIs
• consumers are mobile/web clients you don’t control
• you integrate with third-party providers

Lower ROI when:

• single codebase + synchronized deploy
• trivial internal APIs

3) Consumer-driven contracts (CDC)

CDC approach:

• consumer defines expectations
• provider verifies it can satisfy those expectations

Lead-level tradeoff:

• more discipline and tooling
• huge reduction in “it worked locally” failures

4) Versioning + compatibility rules

A TL policy should define:

• what changes are backward compatible (adding optional fields)
• what changes require versioning (renaming/removing fields)
• deprecation process and timelines

5) CI/CD integration

Recommended pipeline:

• consumer builds contract and publishes to broker/artifact
• provider pipeline verifies contract(s)
• provider cannot deploy if verification fails

6) Interview angle

Be ready to explain:

• the difference between contract tests and integration tests
• where contract tests fit in your deployment model
• how you handle API evolution

7) Review checklist

• [ ] Contract testing is used for independently deployed boundaries.
• [ ] Compatibility rules are documented.
• [ ] Contracts are verified in provider CI.
• [ ] Breaking changes require explicit versioning.
• [ ] Error shapes are treated as part of the contract.