liveBook · Manning

Contract testing

As explained in Secure APIs

Contract testing is a testing approach that verifies an API implementation conforms to an agreed API contract or specification.

Contract testing verifies that an API implementation follows its agreed specification. The specification acts as a contract describing endpoints, parameters, responses, and constraints that consumers can rely on. section 1.2.2 section 12.3

It catches API drift: documented endpoints or parameters may be missing, while implemented behavior may ignore documented limits. Such gaps can frustrate users, expose unintended behavior, or let attackers send oversized requests that strain services. section 12.3 section 6.1

Testing an OpenAPI implementation

Schemathesis reads an OpenAPI specification and dynamically generates valid, invalid, random, malicious, and malformed payloads. A command such as `schemathesis run openapi.json --base-url http://localhost:8000 --checks=all` checks server errors, status codes, response schemas, negative-data rejection, and ignored authentication. A failing test can expose a database error caused by an unexpected NUL byte, rather than merely reporting that a request was unusual. section 12.3

Figure 12.4 API drift is the difference between the API specification and the implementation. In this example, the specification documents an orphan endpoint, GET /courses/{course_id}/details, that is not implemented, so it responds with 404 when users send a request to that endpoint.
figure

An orphan endpoint illustrates drift directly: the specification documents `GET /courses/{course_id}/details`, but the server returns 404 because the implementation is missing. section 12.3

Use contract testing as part of a broader security testing routine:

  • Keep the API specification accurate, including sensible minimum and maximum values for pagination and other resource-consuming parameters. section 6.1
  • Run a contract-testing tool after specification or implementation changes, and investigate failures instead of treating them as harmless malformed input. section 12.3 section 12.6
  • Combine specification checks with API linting, unit tests for business-layer access control, and tests for threat-modelled business flows. section 12.6

How Secure APIs covers it

How deep it goes
Explains drift, generated fuzz cases, checks, and security findings, but stops short of business-layer coverage.
Examples
Uses orphan endpoints, undocumented parameters, pagination limits, Schemathesis commands, and malformed payload failures as concrete examples.
What it assumes
Assumes an API specification and running implementation, while teaching contract testing and fuzz-generated validation from basic principles.
What you can do after
Diagnose API drift and implementation weaknesses by running Schemathesis checks against an OpenAPI specification.
How it connects
Connects API specifications, API drift, fuzzing, API linting, threat modeling, and access control testing.

Also explained in

Compare how 4 books explain contract testing →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Secure APIs. The section links point to the parts of the book it draws on.