Contract testing in Rest API - Step-by-Step Execution

Concept Flow - Contract testing

Define contract

↓

Provider implements API

↓

Consumer writes tests against contract

↓

Run contract tests

↓

Tests pass?

No→Fix provider or consumer

↓

Deploy with confidence

Contract testing ensures that the API provider and consumer agree on the API behavior by defining a contract and testing against it.

Execution Sample

Rest API

contract = {
  "GET /user": {"status": 200, "body": {"id": "int", "name": "string"}}
}

# Consumer test example
response = api_call("GET", "/user")
assert response.status == contract["GET /user"]["status"]
assert type(response.body["id"]) == int
assert type(response.body["name"]) == str

This code checks if the API response matches the contract for the GET /user endpoint.

Execution Table

Step	Action	Evaluation	Result
1	Call GET /user API	Send request to provider	Response received with status 200 and body {"id": 123, "name": "Alice"}
2	Check status code	response.status == 200	True
3	Check body id type	type(response.body["id"]) == int	True
4	Check body name type	type(response.body["name"]) == str	True
5	All contract checks	All True	Test passes, contract fulfilled

💡 All contract conditions met, testing stops successfully

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
response.status	None	200	200	200	200	200
response.body	None	{"id": 123, "name": "Alice"}	{"id": 123, "name": "Alice"}	{"id": 123, "name": "Alice"}	{"id": 123, "name": "Alice"}	{"id": 123, "name": "Alice"}
type(response.body["id"])	None	int	int	int	int	int
type(response.body["name"])	None	str	str	str	str	str

Key Moments - 2 Insights

Why do we check the type of response fields instead of exact values?

Because the contract defines the expected data types, not exact values, so tests verify the structure and type to allow flexibility in actual data (see steps 3 and 4 in execution_table).

What happens if the status code does not match the contract?

The test fails immediately at step 2, indicating the provider does not meet the contract, so deployment should be stopped until fixed.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response status after Step 1?

A 200

B 404

C 500

D None

💡 Hint

Check the 'After Step 1' column for response.status in variable_tracker.

At which step does the test confirm the response body has the correct 'name' type?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Action' column in execution_table for type checks on 'name'.

If the API returned status 404 instead of 200, what would happen in the execution_table?

A Test would fail at Step 4

B Test would pass at Step 2

C Test would fail at Step 2

D Test would pass all steps

💡 Hint

Refer to Step 2 where status code equality is checked.

Concept Snapshot

Contract testing ensures API provider and consumer agree on API behavior.
Define a contract with expected endpoints, status codes, and data types.
Consumer tests call API and check response matches contract.
Tests fail if provider response differs, preventing integration errors.
This builds confidence before deployment.

Full Transcript

Contract testing is a way to make sure the API provider and consumer agree on how the API should behave. First, a contract is defined that lists the expected API endpoints, the status codes they should return, and the types of data in the response. The consumer then writes tests that call the API and check if the response matches this contract. For example, the test checks if the status code is 200 and if the response body fields have the correct data types. If any check fails, the test fails, signaling a problem. This helps catch issues early and ensures both sides work well together before deploying the API.