Status and Content-Type prove you got JSON. They say nothing about whether it's shaped correctly.
Validate the Response Shape (Schema)
Most real breakages return a clean 200 application/json and still break every consumer — a backend renames posterURL, drops imdbId, or sends id as a string. A schema test pins down the contract: these fields exist, with these types, on every record.
In Agent Mode, run a prompt like:
On the "GET /movies/animation" request, add a post-response test that asserts the body is an array and that every item has the required fields with correct types: id (number), title (string), posterURL (string), and imdbId (string).
Confirm the generated test iterates over every item, not just the first — a test that only checks movies[0] misses the one malformed record that causes an incident.
See it for yourself: Send GET /movies/animation and open the Test Results tab — the schema test should show a green PASSED, confirming every item has the required fields and types.
Assert Specific Values on a Known Record
A schema test proves the response has the right shape; it can't prove the data is correct. GET /movies/animation/1 should return the movie with id 1 — not id 7 from an off-by-one bug. Value assertions on a known record catch logic errors a type check sails past.
In Agent Mode, run a prompt like:
On the "GET /movies/animation/:id" request, set the id path variable to 1, then add a post-response test that asserts the returned object's id equals 1.
Avoid over-asserting on volatile fields like title — a good test fails when the behavior breaks, not every time someone fixes a typo in the data.
See it for yourself: Send GET /movies/animation/1 and open the Test Results tab — the value test should show a green PASSED, with the returned id equal to 1.