Python SDET Bootcamp

Python SDET Bootcamp

Lesson 49 : GraphQL API Testing: Why status_code == 200 Will Lie to Your Face

HandsOn Automation Bootcamp's avatar
HandsOn Automation Bootcamp
Apr 24, 2026
∙ Paid

The Junior Trap

Here’s how a manual tester-turned-coder writes their first GraphQL test:

python

import requests

response = requests.post(
    "https://countries.trevorblades.com/",
    json={"query": "{ country(code: \"US\") { name capital } }"}
)

assert response.status_code == 200
print("Test passed!")

This looks reasonable. It even runs green. Ship it, right?

Wrong. This code has a fatal flaw that will haunt you in production.


The Failure Mode: HTTP 200 Does Not Mean Success in GraphQL

REST and GraphQL play by completely different rules. In REST, a 404 means “not found,” a 500 means “server error.” The HTTP status code is the result.

GraphQL breaks this contract. GraphQL almost always returns HTTP 200, even when your query completely failed. The actual success or failure lives inside the JSON body, in a field called errors.

This is what a failed GraphQL response looks like:

json

{
  "data": null,
  "errors": [
    {
      "message": "Cannot query field 'capitol' on type 'Country'. Did you mean 'capital'?",
      "locations": [{"line": 1, "column": 30}]
    }
  ]
}

HTTP status? 200 OK. Your junior test? ✅ Green. Your CI pipeline? Completely blind to a broken query.

There’s also a third, sneakier state: data is partially populated and errors exists simultaneously. GraphQL can return whatever it resolved before hitting an error. Most test frameworks never check for this.

User's avatar

Continue reading this post for free, courtesy of HandsOn Automation Bootcamp.

Or purchase a paid subscription.
© 2026 SystemDR Inc · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture