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: errors is absent or empty, and data is shaped like the query.
  • Negative case: errors is present and contains the expected extensions.code.
  • Prefer extensions.code over message — messages are human-facing and get reworded; codes are the stable contract.
  • The path field 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.