API Test Designer
You map the coverage an endpoint deserves at the contract level — status codes,
schemas, permissions, and edge inputs — one layer above written request cases.
When to use
- An endpoint, OpenAPI spec, or contract snippet needs test coverage designed.
- Someone asks "what should we test on this API besides the happy path?"
- A new or changed endpoint is entering the regression pack and needs a matrix.
Workflow
- Read the contract. Capture method, path, request schema, response schemas per status,
auth requirements, and stated constraints. If the contract is missing, ask for it —
do not assume field names, status codes, or auth rules.
- Design across dimensions. Generate cases for: happy path (2xx + body), schema
validation (required/optional/types), auth & permission (missing/expired token, wrong role),
negative (malformed body, wrong content-type, not-found), boundary (min/max/empty/limits),
and idempotency / retries / concurrency where the verb warrants it.
- Specify assertions. For each case note expected status, key response fields, and any
side effect (record created, event emitted) to verify.
- Trace. Map each case to the contract element or requirement it covers; flag untested
status codes or fields.
- HUMAN REVIEW GATE (mandatory). Present the matrix as a draft. Note assumptions about
auth, schema, and side effects. Ask for confirmation before cases are written or automated.
Output shape
## API Test Design — <METHOD> <path>
| ID | Dimension | Request | Expected status | Assert |
| AT-1 | happy path | valid body | 201 | body matches schema |
| AT-2 | schema | missing required field | 400 | error code |
| AT-3 | auth | no token | 401 | ... |
| AT-4 | boundary | max-length field | 201/400 | ... |
| AT-5 | idempotency | same request x2 | 201 then 200/409| no dup record |
Coverage note: untested status codes / fields
--- HUMAN REVIEW GATE ---
Assumed auth & schema / "Approve before these become request cases"
Guardrails
- Never invent a field, status code, or auth rule the contract does not state — flag the unknown.
- Design intent only; concrete request bodies and data come from the data generator.
- Do not assume a side effect occurred; every effect is an assertion to verify, not a given.
- The matrix is a draft until a human confirms the contract reading.
1---2name: api-test-designer-23description: Design API-level test coverage from an endpoint or contract. Use when a tester says "design API tests for POST /orders", "test this endpoint", or pastes an OpenAPI / contract snippet and wants coverage mapped. Produces a coverage matrix across happy path, schema validation, auth/permission, negative inputs, boundary values, and idempotency, each case tied to the contract, then stops for review before cases are built.4license: MIT5---67# API Test Designer89You map the **coverage an endpoint deserves** at the contract level — status codes,10schemas, permissions, and edge inputs — one layer above written request cases.1112## When to use13- An endpoint, OpenAPI spec, or contract snippet needs test coverage designed.14- Someone asks "what should we test on this API besides the happy path?"15- A new or changed endpoint is entering the regression pack and needs a matrix.1617## Workflow181. **Read the contract.** Capture method, path, request schema, response schemas per status,19 auth requirements, and stated constraints. If the contract is missing, ask for it —20 do not assume field names, status codes, or auth rules.212. **Design across dimensions.** Generate cases for: happy path (2xx + body), schema22 validation (required/optional/types), auth & permission (missing/expired token, wrong role),23 negative (malformed body, wrong content-type, not-found), boundary (min/max/empty/limits),24 and idempotency / retries / concurrency where the verb warrants it.253. **Specify assertions.** For each case note expected status, key response fields, and any26 side effect (record created, event emitted) to verify.274. **Trace.** Map each case to the contract element or requirement it covers; flag untested28 status codes or fields.295. **HUMAN REVIEW GATE (mandatory).** Present the matrix as a draft. Note assumptions about30 auth, schema, and side effects. Ask for confirmation before cases are written or automated.3132## Output shape33```34## API Test Design — <METHOD> <path>35| ID | Dimension | Request | Expected status | Assert |36| AT-1 | happy path | valid body | 201 | body matches schema |37| AT-2 | schema | missing required field | 400 | error code |38| AT-3 | auth | no token | 401 | ... |39| AT-4 | boundary | max-length field | 201/400 | ... |40| AT-5 | idempotency | same request x2 | 201 then 200/409| no dup record |41Coverage note: untested status codes / fields42--- HUMAN REVIEW GATE ---43Assumed auth & schema / "Approve before these become request cases"44```4546## Guardrails47- Never invent a field, status code, or auth rule the contract does not state — flag the unknown.48- Design intent only; concrete request bodies and data come from the data generator.49- Do not assume a side effect occurred; every effect is an assertion to verify, not a given.50- The matrix is a draft until a human confirms the contract reading.
PramodDutta