Q1 of 20 · GraphQL
How does testing a GraphQL API differ from testing a REST API?
GraphQLJuniorgraphqlrestfundamentalsapi
Short answer
Short answer: GraphQL uses a single endpoint where the client specifies exactly which fields it wants, so you test operations rather than URLs. The biggest shift: GraphQL usually returns 200 OK even on errors, so you assert on the response body's data and errors fields, not the HTTP status.
Detail
REST exposes many URLs (one per resource) and signals success or failure through HTTP status codes. GraphQL exposes a single endpoint (typically POST /graphql) and the client sends a query describing exactly the fields it wants back.
The practical testing differences:
- You test operations, not paths. There's no
GET /users/42to assert against — there's auser(id: 42)query and you verify the operation and its field selection. - Status codes stop being your error signal. A logically failed GraphQL request normally comes back as
200 OKwith anerrorsarray in the body. Assertingstatus === 200proves almost nothing — you assert onbody.dataandbody.errors. - The client controls the response shape. Because the query picks fields, you can (and should) test that requesting fewer fields returns fewer fields, and that requesting an unknown field is rejected.
- The schema is a contract you can query. Introspection lets you discover and assert against types and nullability at runtime.
The mental model shift is the main thing interviewers probe: a tester who carries REST habits over will write status-code assertions that pass broken responses.
// WHAT INTERVIEWERS LOOK FOR
The single-endpoint/field-selection model, and specifically that GraphQL returns 200 on errors so body assertions replace status assertions.
// COMMON PITFALL
Saying 'it's just JSON over POST' and missing that status codes no longer indicate success — the exact habit that lets broken responses pass.