What is API contract testing, and how is it different from running a full integration test between two services?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Checks whether the candidate understands that a contract test verifies the agreed request/response shape between a consumer and provider in isolation, rather than spinning up both live services end to end.

What to say

• Define a contract test as a check that the consumer's expectations of an API (status codes, fields, types) match what the provider actually returns, verified against a shared contract rather than the live service.
• Contrast it with integration testing: a contract test runs each side in isolation against the recorded contract, so it is faster and more stable than standing up both real services and their dependencies.
• Explain the payoff: it catches a provider removing or renaming a field before that change reaches the consumer, without a slow flaky end-to-end suite.

What to avoid

• Don't conflate it with end-to-end testing or claim it requires both services running together at once.
• Don't reduce it to 'just checking the API works' without naming the consumer/provider expectation that is being pinned down.
• Don't say contract testing replaces all other testing; it covers the interface, not business workflows.

Example answers

Strong: A contract test pins the shape of the agreement between a consumer and a provider: the consumer declares it expects a 200 with an `id` and `email` field, and that expectation is verified against the provider in isolation. An integration test would instead call the real running provider over the network, which is slower and breaks for reasons unrelated to the contract, like a flaky database.

Weak: Contract testing is basically integration testing; you run both services and check the API returns what you expect.