Q2 of 20 · GraphQL
How does GraphQL report errors, and how should you assert on them?
GraphQLJuniorgraphqlerror-handlingapifundamentals
Short answer
Short answer: Errors come back in an `errors` array in the response body, usually with HTTP 200. Assert on the presence/absence of `errors` and on a stable `extensions.code` rather than the human-readable `message`, which changes over time.
Detail
A GraphQL response is an object with up to two top-level keys: data and errors. A failed operation populates errors — typically still under HTTP 200.
{
"data": { "user": null },
"errors": [
{ "message": "User not found", "path": ["user"], "extensions": { "code": "NOT_FOUND" } }
]
}
How to assert:
- Success case:
errorsis absent or empty, anddatais shaped like the query. - Negative case:
errorsis present and contains the expectedextensions.code. - Prefer
extensions.codeovermessage— messages are human-facing and get reworded; codes are the stable contract. - The
pathfield tells you which field in the query failed, useful for nested assertions.
The error array is the heart of GraphQL testing — most GraphQL test gaps come from never looking at it.
// WHAT INTERVIEWERS LOOK FOR
Knowing errors live in the body not the status, and asserting on extensions.code rather than message for stability.
// COMMON PITFALL
Asserting on the message string — tests then break whenever someone edits copy, and teams learn to ignore them.
// Related questions