Schema testing in GraphQL - Step-by-Step Execution

Concept Flow - Schema testing

Define Schema

↓

Write Test Queries/Mutations

↓

Run Tests Against Schema

↓

Check Responses Match Expected

↓

Pass or Fail Test

↓

Fix Schema or Tests if Fail

↩Back to Write Test Queries

Schema testing means writing queries or mutations to check if the GraphQL schema works as expected, then running these tests and fixing issues if tests fail.

Execution Sample

GraphQL

query GetUser {
  user(id: "1") {
    id
    name
  }
}

This query asks the schema for a user with id 1 and requests the id and name fields.

Execution Table

Step	Action	Query Part	Schema Check	Result
1	Parse Query	query GetUser	Valid syntax	Pass
2	Validate Field 'user'	user(id: "1")	Field exists with argument id	Pass
3	Validate Subfields	id, name	Fields exist on User type	Pass
4	Execute Resolver	user with id=1	Returns user object	{"id":"1","name":"Alice"}
5	Compare Response	Response vs Expected	Matches expected data	Pass

💡 All schema checks passed and response matched expected data

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
query	undefined	Parsed query object	Validated fields	Executed resolver	Response data
response	undefined	undefined	undefined	{"id":"1","name":"Alice"}	{"id":"1","name":"Alice"}

Key Moments - 2 Insights

Why do we check if fields exist on the User type?

Because if a field does not exist on the type, the schema is invalid for that query. See execution_table row 3 where subfields are validated.

What happens if the resolver returns wrong data?

The test will fail at the response comparison step (row 5), indicating the schema or resolver logic needs fixing.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result of validating the 'user' field?

A Pass

B Fail

C Skipped

D Error

💡 Hint

Check execution_table row 2 under Result column

At which step is the resolver executed?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at execution_table Step column and Action 'Execute Resolver'

If the response data did not match expected, which step would show failure?

A Step 3

B Step 4

C Step 5

D Step 1

💡 Hint

See execution_table row 5 comparing response vs expected

Concept Snapshot

Schema testing in GraphQL:
- Write queries/mutations to test schema
- Validate query syntax and fields
- Execute resolvers to get data
- Compare response with expected
- Fix schema or tests if failures occur

Full Transcript

Schema testing in GraphQL involves writing queries or mutations that ask for data defined in the schema. The process starts by parsing the query to check syntax. Then, each field and argument is validated against the schema to ensure they exist and are correct. After validation, the resolver functions run to fetch or compute the data. The returned response is compared to the expected result to confirm correctness. If any step fails, the schema or test queries are fixed and tested again. This cycle ensures the schema works as intended and helps catch errors early.

Practice

1. What is the main purpose of schema testing in GraphQL?

easy

A. To check the database connection

B. To test the speed of GraphQL queries

C. To verify that the GraphQL schema matches the expected structure and types

D. To validate user authentication tokens

Solution

1. Step 1: Understand schema testing purpose

   Schema testing ensures the GraphQL schema is correct and matches the design.

2. Step 2: Compare options to purpose

   Only verifying schema structure and types matches schema testing's goal.

3. Final Answer:

   To verify that the GraphQL schema matches the expected structure and types -> Option C

4. Quick Check:

   Schema testing = verify schema structure [OK]

Hint: Schema testing checks schema structure, not performance or auth [OK]

Common Mistakes:

• Confusing schema testing with performance testing
• Thinking schema testing checks database connections
• Assuming schema testing validates user authentication

2. Which of the following is the correct syntax to define a GraphQL schema type for a User with fields id (ID!) and name (String)?

easy

A. User { id: ID! name: String }

B. schema User { id: ID! name: String }

C. type User (id: ID!, name: String)

D. type User { id: ID! name: String }

Solution

1. Step 1: Recall GraphQL type syntax

   GraphQL types use the keyword type followed by name and curly braces with fields.

2. Step 2: Match syntax to options

   type User { id: ID! name: String } correctly uses type User { id: ID! name: String }. Others misuse keywords or punctuation.

3. Final Answer:

   type User { id: ID! name: String } -> Option D

4. Quick Check:

   Correct type syntax = type User { id: ID! name: String } [OK]

Hint: GraphQL types start with 'type' keyword and use braces {} [OK]

Common Mistakes:

• Using 'schema' instead of 'type' keyword
• Using parentheses instead of braces
• Omitting the 'type' keyword

3. Given this GraphQL schema snippet:

type Query { user(id: ID!): User }

And this query:

{ user(id: "123") { id name } }

What is the expected shape of the response data?

medium

A. {"user": {"id": "123", "name": "Alice"}}

B. {"data": {"user": {"id": "123", "name": "Alice"}}}

C. {"data": {"user": null}}

D. {"error": "User not found"}

Solution

1. Step 1: Understand GraphQL response format

   GraphQL responses wrap results inside a data object with requested fields.

2. Step 2: Match query and schema to response

   The query requests user with id "123" and fields id and name. Assuming user exists, response includes these inside data.

3. Final Answer:

   {"data": {"user": {"id": "123", "name": "Alice"}}} -> Option B

4. Quick Check:

   GraphQL response wraps data in 'data' key [OK]

Hint: GraphQL responses always wrap results inside 'data' key [OK]

Common Mistakes:

• Returning data without 'data' wrapper
• Confusing null user with error response
• Assuming error is returned instead of null

4. You wrote this schema test to check if the email field exists on User type:

expect(schema.getType('User').getFields()).toHaveProperty('email')

But the test fails. What is the most likely cause?

medium

A. The User type does not have an email field defined

B. The getFields() method is not valid on schema types

C. The test syntax is incorrect and should use hasProperty

D. The schema variable is undefined

Solution

1. Step 1: Understand what getFields() returns

   The getFields() method returns an object of fields defined on the type.

2. Step 2: Analyze test failure reason

   If test fails checking for 'email', likely the User type lacks that field in schema definition.

3. Final Answer:

   The User type does not have an email field defined -> Option A

4. Quick Check:

   Missing field causes test failure [OK]

Hint: Test fails if field is missing in schema type [OK]

Common Mistakes:

• Assuming method getFields() is invalid
• Confusing test assertion method names
• Not checking if schema variable is defined

5. You want to write a schema test to ensure the Post type has a field comments that returns a list of Comment types. Which test code correctly verifies this?

hard

A. expect(schema.getType('Post').getFields().comments.type.toString()).toBe('[Comment!]!')

B. expect(schema.getType('Post').getFields().comments.type.ofType.name).toBe('Comment')

C. expect(schema.getType('Post').getFields().comments.type.toString()).toBe('[Comment]')

D. expect(schema.getType('Post').getFields().comments.type.name).toBe('Comment')

Solution

1. Step 1: Understand GraphQL list and non-null syntax

   A list of Comment types with non-null items and non-null list is represented as [Comment!]!.

2. Step 2: Match test code to expected type string

   expect(schema.getType('Post').getFields().comments.type.toString()).toBe('[Comment!]!') checks the full type string including non-null markers, correctly verifying the list of non-null Comments.

3. Final Answer:

   expect(schema.getType('Post').getFields().comments.type.toString()).toBe('[Comment!]!') -> Option A

4. Quick Check:

   List of non-null Comments = '[Comment!]!' [OK]

Hint: Use toString() to check full list and non-null type syntax [OK]

Common Mistakes:

• Checking only inner type name without list brackets
• Ignoring non-null markers in type string
• Using wrong property to access type name