Contract testing

Continuous contract validation, on every change.

Kerno pins every response contract from your code, field by field, and catches a breaking change before it reaches your consumers.

GET /orders/:idcontract run
RAN AGAINSTYOUR APPSUT:8080
DEPENDENCIESpostgresdb
every response field pinnedpass
field types and formats unchangedpass
shipping_eta dropped from the responsediff
-"shipping_eta": "2026-09-11"
+(field absent)
error contract matches the frameworkpass
16 contracts · 15 pass · 1 diff
Agents and engineers at these companies use Kerno
Built from your code

Every contract comes from your code and is checked against your running service.

Contracts from your code

Kerno reads the response model your framework declares and pins the assertion to it, field by field.

Exhaustive field assertions

Every field a response returns is asserted, so a dropped, renamed or added field shows up as a failure.

Error contract pinning

The body your framework returns on failure is pinned the same way, down to the code and message fields.

Live service verification

Every contract is checked against what your running service returns, on your real data and dependencies.

Volatile value handling

Ids, timestamps and tokens are matched on the shape they take, so a new value stays a passing test.

CI enforcement

Your committed contract tests replay on every pull request, and a changed shape fails the check.

Full coverage

Catches dropped fields, type changes and error-shape drift on every response.

01

Response structure

Objects, arrays, nesting, and the shape every response returns.

02

Types and formats

Field types, enums, date and time formats, and numeric precision.

03

Required fields

Presence, nullability, and the fields a consumer can rely on.

04

Error contracts

Status codes, error bodies, and the shape returned on failure.

05

Generated values

Ids, timestamps, and tokens, matched on the shape they take.

06

Contract drift

Dropped fields, renamed keys, and shapes that change between runs.

  • TypeScript
  • JavaScript
  • Python
  • Java
  • Kotlin
  • PostgreSQL
  • MySQL
  • MariaDB
  • MongoDB
  • Redis
  • Kafka
  • RabbitMQ
  • AWS
  • Azure
  • ClickHouse
  • Google Cloud
Learns your standards

Kerno applies your rules and standards to every contract it pins from your code.

Reads your rules and standards in plain English

Write a rule the way you would explain it to a new engineer, and scope it to the repositories and paths it applies to.

Works from the context your team already wrote

Agent instruction files, service READMEs and the docs in your repository shape how every contract gets pinned.

Gets more accurate with every run you review

Kerno learns from each run and the feedback you give it, and carries what it learns into the checks that follow.

FAQs

Got any extra questions? Reach out on our community channel and we'll be happy to help.

What does contract validation cover in Kerno?

Kerno pins each endpoint's response and error contracts field by field, and flags any drift in structure, types, or required fields as a diff.

Does Kerno do consumer-driven (Pact) contract testing?

Kerno validates each service's response contracts and flags schema drift within that service. It does not yet generate or verify consumer-driven, Pact-style contracts across services.

Does Kerno need a schema file?

No. Kerno reads the serializer or DTO in your code, so it validates the contract whether or not you publish a schema.

How does Kerno catch a breaking API change?

Kerno asserts every field a response returns, so a dropped or renamed field fails on the next run and shows up as a diff against the baseline.

Which frameworks can Kerno read a contract from?

Kerno reads the response model your framework declares, with dedicated handling for Django REST Framework serializers and deep symbol resolution in TypeScript, Python, Java and Kotlin.

Does contract validation run in CI?

Yes. Committed contract tests replay in CI on every pull request, and a changed response shape fails the check.