Skip to main content

​
Contract testing

Contract testing checks that two services agree on the shape of the messages they exchange. That shared shape, the endpoints, the request and response fields, the data types, and the status codes, is the “contract.” Contract testing confirms each side still honors it, so a change in one service does not silently break the other. It is most useful between a consumer (the caller) and a provider (the API). Consumer-driven tools such as Pact record what the consumer expects and replay it against the provider on every change.

​
Why it matters

Integration bugs often come from a quiet contract break: a field gets renamed, a type changes from string to number, a 200 becomes a 202, or a required field disappears. The caller keeps compiling but fails at runtime. Contract testing catches these before they ship.

​
How Qodex relates to contract testing

Qodex imports your OpenAPI or Swagger spec and can validate live API responses against that schema and against your plain-English assertions. A renamed field, a wrong type, a missing required property, or an unexpected status code shows up as a failing scenario, which catches many of the same breaks contract testing targets. Qodex is not a dedicated consumer-driven contract framework like Pact; it does not broker a signed contract between two teams. It verifies that your real API still matches its declared spec and expected behavior, continuously, on every pull request and deploy.

API testing

Import a spec and author scenarios against real endpoints.

Import an OpenAPI spec

Parse OpenAPI or Swagger into the endpoint catalog.

Test rules in plain English

Write response assertions in natural language.

Auto-verification on save

Run a new API scenario against the target immediately.