advanced

Generate API Contract Tests from OpenAPI Spec

Create a reviewable API contract test suite that validates response schemas, status codes, headers, and error payloads against an OpenAPI 3.0 spec.

Who this is for

QA engineers and SDETs working with REST APIs who want to automatically verify that API responses match their OpenAPI/Swagger specification — preventing breaking changes from reaching consumers.

Prompt Template

You are a senior SDET specialising in API contract testing.

Generate a complete contract test suite using {{framework}} that validates the {{apiName}} API against its OpenAPI 3.0 specification.

OpenAPI spec location: {{specPath}}
Base URL: {{baseUrl}}
Auth: {{authMethod}}

For each endpoint in the spec, generate tests that verify:
1. Response status codes match the spec for both success and error cases
2. Response body schema matches exactly (required fields, types, formats)
3. Response headers are present and correctly typed
4. Error payloads match the spec's error schema
5. Required request parameters are validated
6. Nullable fields handle null correctly
7. Enum values are validated
8. Date/time formats are correct (ISO 8601)

Additional requirements:
- Use a schema validation library (Zod / Ajv / joi based on {{framework}})
- Load the OpenAPI spec dynamically to stay in sync
- Group tests by endpoint and HTTP method
- Include tests for 400, 401, 403, 404, 422, 500 responses
- Generate test data that covers boundary conditions

How to use this prompt

1Copy the prompt and provide your OpenAPI spec URL or paste the spec content.
2Specify your testing framework (Postman, pytest, Jest/Supertest, REST-assured).
3Indicate which endpoints and HTTP methods you want contract tests for.
4The AI generates contract tests that validate response schema, status codes, required fields, and data types against your spec.
5Run the tests in your CI pipeline to catch spec deviations before they reach staging or production.

Example output

For a /users/{id} GET endpoint, the prompt generates tests that: verify HTTP 200 status, validate the response schema matches the OpenAPI definition (all required fields present, correct types), check that 404 is returned for non-existent IDs, and verify that the response does not include undocumented fields that could leak PII.

Limitations

Contract tests validate the response shape, not the business logic — use them alongside functional tests, not as a replacement.
If your OpenAPI spec is incomplete or inaccurate, the generated tests will reflect those gaps — fix the spec first.
Does not cover authentication flows — add auth setup separately in your test framework's configuration.

API Response Inspector

api testing fundamentals

Frequently asked questions

What is the difference between contract testing and integration testing?v

Integration testing checks that two systems work together end-to-end. Contract testing specifically validates that the API response shape matches a defined spec — it's faster and more targeted, running without the full system being live.

Does this work with GraphQL?v

This prompt is optimised for REST/OpenAPI. For GraphQL, use the GraphQL schema as your contract and specify 'GraphQL' in the framework placeholder — the prompt will adapt the test structure.

Can I run contract tests in CI without a live API?v

For consumer-driven contracts, you can use a mock server (e.g. WireMock, MSW) to run contract tests against recorded responses. The prompt can generate both live and mock-server variants.