git:20260714.b87d8d4 to git:20261006.b9ea321

---

name: api-test-plan

description: "Plan tests for an API endpoint or service — functional, negative, and contract. Use when asked to test an API, write API test cases, plan REST/GraphQL endpoint testing, or validate an API contract. Produces an API test plan — per-endpoint cases (status codes, schema, auth, validation, errors), boundary/negative cases, contract checks, and non-functional notes — so the API is verified beyond the happy 200."

homepage: https://mohitagw15856.github.io/pm-claude-skills/skill/api-test-plan.html

metadata:

{

"openclaw": { "emoji": "🧪" }

}

---

# API Test Plan Skill

APIs fail in specific, testable ways: wrong status codes, schema drift, missing auth checks, sloppy validation,

unhelpful errors. This skill plans the tests that catch them — per endpoint, across the response codes and the

error paths, with contract checks so the API keeps its promises to clients. It tests the whole behaviour, not

just the happy `200`.

## Working from a brief

Given an endpoint or an API description, **produce the test plan anyway** — infer the likely parameters,

responses, auth model, and error cases, labelling assumptions. Always include auth, validation, and negative

cases. Never hand back a question instead of a plan.

## Required Inputs

Ask for these only if they aren't already provided (else infer and label):

- **The API** — REST/GraphQL, the endpoints/operations, and what they do.

- **Contract** — request/response schemas, parameters, status codes (or an OpenAPI/spec if available).

- **Auth & rules** — the auth model (token/scopes/roles), rate limits, and validation rules.

- **Dependencies & data** — downstream services, and the data/state needed to test.

## Output Format

### API Test Plan: [API / endpoint]

**Per endpoint**, a set of cases grouped by type:

| ID | Endpoint | Case | Type | Request | Expected status | Expected body / assertion |

|---|---|---|---|---|---|---|

| API-01 | POST /orders | valid create | Functional | valid payload | 201 | body matches schema, id returned |

| API-02 | POST /orders | missing field | Validation | partial payload | 400 | error names the field |

| API-03 | POST /orders | no token | Auth | valid payload, no auth | 401 | not created |

| API-04 | POST /orders | wrong role | Authz | valid payload, wrong scope | 403 | not created |

| API-05 | GET /orders/{id} | not found | Negative | unknown id | 404 | error body |

Cover deliberately: **happy path** (correct status + schema), **validation** (missing/invalid/extra fields, types, boundaries), **auth/authz** (no token, expired, wrong scope/role), **negative** (not found, conflict, bad method), **idempotency/concurrency** where relevant, and **errors** (correct codes + helpful, consistent error bodies).

**Contract checks** — responses conform to the schema; required fields, types, and status codes match the spec; backward compatibility for existing clients.

**Non-functional notes** — rate limiting, pagination, large payloads, latency expectations, and security basics (no sensitive data leakage, proper status for unauthorised).

**Setup** — test data, environment, and any mocks/stubs for dependencies.

## Quality Checks

- [ ] Each endpoint is tested beyond 200 — error codes (4xx/5xx) and their bodies are asserted

- [ ] Auth and authorization cases are included (no token, expired, wrong scope/role)

- [ ] Validation/boundary/negative cases cover missing, invalid, and extra inputs

- [ ] Responses are checked against the schema/contract, incl. backward compatibility

- [ ] Status codes match the spec and are used correctly (e.g. 401 vs. 403, 400 vs. 422)

- [ ] Non-functional aspects (rate limits, pagination, data leakage) are noted

## Anti-Patterns

- [ ] Do not test only the happy 200 — most API bugs are in validation, auth, and error paths

- [ ] Do not ignore the response schema — a 200 with the wrong body still breaks clients

- [ ] Do not skip authz (role/scope) testing — "logged in" isn't "allowed"

- [ ] Do not assert only status codes — check the body/contract too

- [ ] Do not overlook error-body quality and correct status semantics (401 vs 403, 400 vs 404)

## Based On

API testing practice — contract/schema validation, status-code correctness, auth/authz coverage, and negative/boundary testing beyond the happy path.