Skip to content

Generate an API Test Suite from OpenAPI Spec

Updated 2026-06-08·intermediate·Test Automation

Reads an OpenAPI 3.x specification and returns an API test suite that validates response schemas per documented status code, covers authentication, pagination, filtering, and the standard error responses (400, 401, 403, 404, 429, 500). Output is framework-agnostic plan plus Playwright APIRequestContext skeleton.

When to use it

  • You have an OpenAPI spec and need to scaffold API tests fast.
  • You're enforcing API contracts via tests instead of (or alongside) Pact contract testing.
  • You want consistent rate-limit, auth, and pagination coverage across all endpoints.
  • You're auditing API test coverage gaps against the actual spec.

The prompt

XML-tagged — best for Claude 4.x

<role>
You are an API testing specialist who has shipped suites for production REST APIs. You validate response schemas via $ref rather than redefining them, and you cover the standard error cases (400, 401, 403, 404, 429, 500) per endpoint instead of just happy paths.
</role>

<context>
The team uses Playwright's APIRequestContext for API tests (also acceptable: supertest, axios + Jest, REST Assured). Tests run in CI against a deployed staging environment with seeded data. Schema validation uses Ajv with refs into the original spec.
</context>

<task>
For the OpenAPI snippet I provide, generate:
1. A test plan (Markdown table) listing test cases per endpoint × status code, grouped by happy path, auth, error responses, pagination/filtering, rate limiting.
2. A Playwright APIRequestContext skeleton file demonstrating: schema validation via $ref, parameterized status code tests, auth header injection via fixture, pagination loop test.
3. Identify gaps in the spec (missing 429 docs, ambiguous schemas, undocumented auth) — list them separately.
</task>

<input>
OpenAPI snippet (paths + components excerpt): {openapi}
Auth scheme (Bearer, API key, OAuth): {auth}
Framework preference: {framework}
</input>

<constraints>
- Test plan covers EVERY documented status code per endpoint, not just 2xx.
- Schema validation references components via $ref — never inline duplicate schemas.
- Auth header injection is a single fixture, not repeated per test.
- Rate limit testing (429) is mandatory when documented; flagged as missing if not documented.
- Pagination test exercises both first-page and middle-page (cursor or offset).
</constraints>

<output_format>
Three sections:
1. **Test plan** — Markdown table with columns: Endpoint, Method, Status, Test case, Priority.
2. **Skeleton code** — Playwright APIRequestContext code block.
3. **Spec gaps** — bullet list of missing or ambiguous spec content.
</output_format>

Before writing, scan the spec for what's documented vs missing.

Example

Common pitfalls

  • Model writes schema validation by inline-redefining the schema instead of $ref — refs are essential for spec drift detection.
  • Pagination test asserts a fixed page size instead of behavior — review whether the test would catch a regression to 'returns all 10000 rows'.
  • Auth fixture gets duplicated across test files instead of a single shared fixture — extract immediately.
  • Rate limit tests pass against a non-rate-limited staging env and fail in prod. Run them in an env that actually has limits enabled.

Tips

  • When the spec changes, re-run the prompt and diff the test plan against the previous version — you'll see exactly which test cases need updating.
  • Use the 'Spec gaps' section as your bug-tracker for the API team — these are real ambiguities that hurt every consumer.
  • For OAuth flows, generate the auth fixture separately (it's complex enough to deserve its own prompt run).
  • Pair this prompt with `api-rate-limiting-tests` to deepen 429 coverage.

FAQ

Ajv (Node.js) for JSON Schema is the standard. For Pact-style contract tests, use Pact directly. For Python, jsonschema. For Java, the validator that ships with REST Assured. The principle — validate against the original spec, not a copy — is more important than the library.

Related prompts

Use with these tools