How do I test contract changes between microservices?

To test contract changes between microservices, the goal is to catch breaking API/message changes before deployment. The most common and effective approach is consumer-driven contract testing.

1) Use consumer-driven contracts

Each consumer service defines what it expects from a provider service.

• Consumer writes a contract for the request/response it needs.
• Provider verifies it can satisfy that contract.
• If the provider changes the API in a breaking way, the verification fails.

Common tools

• Pact (most popular for HTTP and messaging)
• Spring Cloud Contract (great for Spring-based stacks)
• OpenAPI/Swagger contract validation (good for REST, but more schema-based than consumer-driven)
• AsyncAPI for event/message contracts

2) Test both request and response shapes

Validate:

• required fields
• data types
• optional vs mandatory fields
• status codes
• headers
• error responses
• enum values and format constraints

This helps detect changes like:

• renamed fields
• removed fields
• changed response codes
• stricter validation rules
• altered event payloads

3) Run provider verification in CI/CD

Typical flow:

1. Consumer publishes contract to a contract broker or repo.
2. Provider fetches latest contracts.
3. Provider runs verification tests against its implementation.
4. Build fails if compatibility is broken.

This is especially useful when teams deploy independently.

4) Backward compatibility testing

When making changes, check:

• Can the provider still satisfy older consumer contracts?
• Is the new version additive rather than breaking?
• Are you versioning APIs/messages properly?

Prefer:

• adding fields instead of removing/renaming
• keeping old fields temporarily
• introducing new endpoints or versions for breaking changes

5) Test event/message contracts too

If microservices communicate via Kafka, RabbitMQ, SNS/SQS, etc.:

• validate event schemas
• enforce schema evolution rules
• verify producers don’t break consumers

Tools/patterns:

• Schema Registry (Avro/Protobuf/JSON Schema)
• AsyncAPI
• Pact message contracts

6) Add integration tests, but don’t rely on them alone

End-to-end tests are useful, but they are:

• slower
• more brittle
• harder to pinpoint failures

Use them as a safety net, not the primary contract-checking mechanism.

7) Practical testing strategy

A good layered approach is:

• Unit tests: service logic
• Contract tests: API/message compatibility
• Integration tests: real dependencies in a controlled env
• E2E tests: key business flows only

8) Example workflow

For a REST service:

• Consumer defines expected GET /orders/{id} response
• Contract says id, status, and total must exist
• Provider changes total to amount
• Contract verification fails in CI
• Change is fixed or versioned before release

---

If you want, I can also show you:

1. a Pact example,
2. a Spring Cloud Contract setup, or
3. a CI pipeline pattern for contract testing.