🔌 Claude for API Testing

Claude for API Testing: Asking Claude to write API test assertions from a pasted response JSON is like asking an inspector to write a building code checklist after seeing photos

Asking Claude to write API test assertions from a pasted response JSON is like asking an inspector to write a building code checklist after seeing photos of ONE finished room — the mechanism is exact: the photo shows what the response happened to look like this once (the actual JSON), but a good assertion set also needs to cover what happens when the room ISN'T finished correctly (a missing field, a wrong type, an error status) — information the happy-path response alone never shows you. Here is the question worth sitting with: if Claude can read your 200 OK JSON and write perfect assertions for every field in it, why is that suite still incomplete? Because it only saw the happy path — nobody showed it what a 422 validation error or a 500 looks like, so it cannot assert on failure shapes it never saw; you must supply or explicitly request those scenarios. Java comparison: this is like writing JUnit assertions purely from a single passing run's captured output instead of from the actual API contract (the OpenAPI spec) — you'll perfectly test what happened once, and miss what the contract actually promises for edge cases. The QA stake: an API suite that's 100% green but never asserts on a documented 400/401/404/500 behavior gives false confidence exactly where production incidents (bad input, auth failures, downstream timeouts) actually happen.

From Response JSON to Real Assertions

Paste one real response and add the explicit constraint "also ask what happens for X invalid input" — Claude then proposes assertions for the happy path field-by-field and, if asked, hypothesizes plausible 4xx/5xx shapes to also assert once you confirm the real contract.

Reasoning: why paste the OpenAPI spec instead of just describing the endpoint in words? An OpenAPI definition is already the same Given/When/Then-style forcing function as Gherkin — it names every parameter, its required/optional flag and the response schema explicitly, removing exactly the kind of oracle ambiguity discussed in the Test Case Generation tab. If you don't have an OpenAPI spec, describing the endpoint informally still works, but expect more of Claude's output to be flagged assumptions rather than confirmed rules.

When Does the given().when().then() Chain Actually Check What?

given().header(...) does NOT send…

given().header(...) does NOT SEND any request YET — it only DEFINES which headers/parameters get added during the request's SETUP phase.

The moment when().get("/api/users/{id}", 42) is called…

The moment when().get("/api/users/{id}", 42) is called, the real HTTP request is SENT — the {id} placeholder is FILLED with 42 and the request GOES to /api/users/42.

then().statusCode(200) runs AFTER the response…

then().statusCode(200) runs AFTER the response arrives and CHECKS the HTTP status code — if this check FAILS, the test is marked FAILED WITHOUT the following .body(...) lines ever RUNNING.

.body("id", equalTo(42)) and .body("email", ...)…

.body("id", equalTo(42)) and .body("email", notNullValue()) CHAIN multiple independent checks against the SAME response body — each QUERIES its own JSON path.

The // Not yet confirmed comment…