Day 13 of 60 · Unit, integration, contract

Contract testing

In a microservice architecture, "we agreed on the API last sprint" is a fairy tale. Contracts make the agreement machine-checkable, both sides, every PR.

ProblemService A and Service B agree on a contract; either side breaks it without warning.

How it works

Each side declares its expectations as a machine-checkable contract. Pre-merge, both sides verify the contract. Failures block deploy.

What it catches

Cross-service breakages, especially in microservice architectures. Catches what end-to-end tests catch but with 1/10th the runtime.

Tools

Pact · OSS Spring Cloud Contract · OSS JSON Schema · OSS

Verdict by project size

Small
Skip
Medium
Rec
Large
Must
Extra-large
Must

Cost

Project size Setup Maint / mo Tool / mo CI / run
Small <10k LOC 1d 1h $0 +1m
Medium 10–100k LOC 3d 5h $0 +2m
Large 100k–1M LOC 10d 25h $500 +5m
Extra-large >1M LOC 30d 80h $2k +10m
Setup = engineer-days to first useful run · Maint = engineer-hours / month at steady state · Tool = out-of-pocket $ / month · CI = minutes added (or saved) per pipeline run

Lifecycle & ownership

When in lifecycle
Code Test
Per pull request · Runs in CI on every PR; gates merge.
Who owns it
Developer
Authoring + the inner loop
Collaborates with: QA / Test Engineer

Reference implementations

Quick check

In a microservice architecture, contract testing replaces what?

One question. Pick the best answer. Your streak is saved locally on this device.

Save the lesson

Download SVG ↓

Screenshot for a 1:1, drop it in Slack, or download the SVG.

thinkbridge THE VALIDATION ATLAS DAY 13 OF 60 UNIT, INTEGRATION, CONTRACT Contract testing In a microservice architecture, "we agreed on the API lastsprint" is a fairy tale. Contracts make the agreementmachine-checkable, both sides, every PR. FIVE-MINUTE LESSON · ONE QUICK-CHECK QUESTION There’s a new way there
All 60 days →