Course Preview

Contract Testing

Contract testing checks that two services which talk to each other, such as a web front end and an HTTP API, agree on the requests and responses they exchange. Each side is tested separately against a shared record of that agreement, so teams catch breaking changes without starting every service together in one test environment.

itSoftware engineering | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic: Contract Testing

Contract testing is a way to prove that two programs which talk to each other still agree on what they say, without switching both of them on in the same room. The one asking is the consumer. The one answering is the provider. The agreement between them is the contract, and it is written down so both sides can be checked against it separately.

Before this, teams had two options, each disappointing in its own way. The first was a unit test with a stand-in for the provider. That test is fast, but the stand-in only knows what the consumer team believes, and beliefs age badly. The second was an end-to-end test that starts everything at once. It proves more, at the price of a shared environment, slow runs, and the delicate job of getting every correct version in place simultaneously.

The first big idea is that the work splits into two halves that never meet. In the consumer build, your client code talks to a mock provider, a local fake that checks each request and returns the response you expected. Passing tests leave behind a pact file, a JSON record of every request and the smallest response your code needs. In the provider build, a verifier replays those requests against the real provider and checks that each answer contains at least what was asked for.

The second idea is that the contract is made of examples, not a complete schema. It covers only what consumers actually use. Extra fields in a response are ignored, so a provider can add things freely. Removing a field someone reads is what fails. Matching rules let a test say "any integer" instead of "exactly 10", which saves everyone from contracts that break over a changed ID.

The third idea is where the safety actually lives. A Pact Broker stores pact files and verification results and keeps a matrix of which consumer versions work with which provider versions. The can-i-deploy command asks that matrix whether a version is safe to release into an environment, and record-deployment tells it what went out afterwards. Skip either one and the pact files become paperwork.

The surprise is how little a contract promises. It checks the messages, not whether the provider did the right thing with them. An order request can match the contract perfectly while the order itself is saved wrong. Contract tests also suit teams who know their consumers and can talk to them; a public API with unknown consumers is outside the brief. Neither is a flaw. It is the price of being fast.

For the full model, from roles to pending pacts to other ways of writing the contract, read the intro. The slides compress it into flows and comparison tables. The cheatsheet holds matching rules, broker commands, and failure signals. If you prefer to find out by breaking something, the exercise has you write one contract, verify it, and then rename a field to watch verification fail.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources