Integration tests with test server in GraphQL

Introduction

Integration tests check if different parts of your GraphQL server work well together. Using a test server helps you test safely without affecting real data.

When you want to check if your GraphQL queries and mutations work correctly end-to-end.

When you add new features and want to make sure they don't break existing ones.

When you want to test how your server handles real requests and responses.

When you want to catch bugs before your users see them.

When you want to automate testing as part of your development process.

Syntax

GraphQL

import { createTestClient } from 'apollo-server-testing';
import { ApolloServer } from 'apollo-server';

const server = new ApolloServer({ typeDefs, resolvers });
const { query, mutate } = createTestClient(server);

// Use query({ query: YOUR_QUERY }) or mutate({ mutation: YOUR_MUTATION }) to test

You create a test server instance with your schema and resolvers.

Use query to test queries and mutate to test mutations.

Examples

This example tests a query to get a user by ID.

GraphQL

const GET_USER = gql`
  query GetUser($id: ID!) {
    user(id: $id) {
      id
      name
    }
  }
`;

const res = await query({ query: GET_USER, variables: { id: "1" } });

This example tests a mutation to add a new user.

GraphQL

const ADD_USER = gql`
  mutation AddUser($name: String!) {
    addUser(name: $name) {
      id
      name
    }
  }
`;

const res = await mutate({ mutation: ADD_USER, variables: { name: "Alice" } });

Sample Program

This program creates a simple GraphQL test server with a user list. It tests adding a user and then fetching that user by ID.

GraphQL

import { ApolloServer, gql } from 'apollo-server';
import { createTestClient } from 'apollo-server-testing';

// Define schema
const typeDefs = gql`
  type User {
    id: ID!
    name: String!
  }

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

  type Mutation {
    addUser(name: String!): User
  }
`;

// In-memory data
const users = [];
let idCount = 1;

// Resolvers
const resolvers = {
  Query: {
    user: (_, { id }) => users.find(u => u.id === id),
  },
  Mutation: {
    addUser: (_, { name }) => {
      const user = { id: String(idCount++), name };
      users.push(user);
      return user;
    },
  },
};

// Create test server
const server = new ApolloServer({ typeDefs, resolvers });
const { query, mutate } = createTestClient(server);

// Test adding a user
(async () => {
  const ADD_USER = gql`
    mutation AddUser($name: String!) {
      addUser(name: $name) {
        id
        name
      }
    }
  `;

  const resAdd = await mutate({ mutation: ADD_USER, variables: { name: "Bob" } });

  // Test querying the user
  const GET_USER = gql`
    query GetUser($id: ID!) {
      user(id: $id) {
        id
        name
      }
    }
  `;

  const resGet = await query({ query: GET_USER, variables: { id: resAdd.data.addUser.id } });

  console.log(JSON.stringify(resAdd.data));
  console.log(JSON.stringify(resGet.data));
})();

Important Notes

Integration tests run your real schema and resolvers, so they catch more issues than unit tests.

Use an in-memory database or mock data to keep tests fast and isolated.

Always clean or reset data between tests to avoid interference.

Summary

Integration tests check if your GraphQL server parts work together correctly.

Use a test server to safely run queries and mutations without affecting real data.

Write tests for both queries and mutations to cover your API fully.

Practice

1. What is the main purpose of using a test server in GraphQL integration tests?

easy

A. To speed up the production server

B. To run queries and mutations safely without affecting real data

C. To replace the database permanently

D. To generate random data automatically

Solution

1. Step 1: Understand the role of a test server

   A test server is a safe environment that mimics the real server but does not affect actual data.

2. Step 2: Identify the purpose in integration tests

   Integration tests use the test server to check if queries and mutations work together correctly without risk.

3. Final Answer:

   To run queries and mutations safely without affecting real data -> Option B

4. Quick Check:

   Test server = safe testing environment [OK]

Hint: Test server isolates tests from real data changes [OK]

Common Mistakes:

• Thinking test server speeds up production
• Confusing test server with permanent database replacement
• Assuming test server auto-generates data

2. Which of the following is the correct way to start a test server for GraphQL integration tests using Apollo Server?

easy

A. const server = ApolloServer(); server.startServer();

B. const server = ApolloServer(typeDefs, resolvers); server.run();

C. const server = new ApolloServer({ typeDefs, resolvers }); await server.listen();

D. const server = new ApolloServer({ typeDefs, resolvers }); await server.start();

Solution

1. Step 1: Recall Apollo Server setup

   Apollo Server requires creating an instance with typeDefs and resolvers, then calling start() before listen().

2. Step 2: Identify correct method to start server

   The correct method to start the server is await server.start(); before running listen().

3. Final Answer:

   const server = new ApolloServer({ typeDefs, resolvers }); await server.start(); -> Option D

4. Quick Check:

   Use server.start() before listen() [OK]

Hint: Remember to call await server.start() before listen() [OK]

Common Mistakes:

• Calling listen() without starting server
• Using incorrect constructor syntax
• Assuming server.run() or startServer() exist

3. Given this test code snippet for a GraphQL query on a test server:

const result = await server.executeOperation({ query: `query { user(id: 1) { name } }` }); console.log(result.data.user.name);

What will be printed if the user with id 1 has the name "Alice"?

medium

A. undefined

B. null

C. "Alice"

D. Error: user not found

Solution

1. Step 1: Understand executeOperation result

   executeOperation returns an object with data containing the query result if successful.

2. Step 2: Check the query and expected data

   The query requests user with id 1 and its name. If user exists with name "Alice", result.data.user.name will be "Alice".

3. Final Answer:

   "Alice" -> Option C

4. Quick Check:

   Query result matches user name "Alice" [OK]

Hint: executeOperation returns data object with query results [OK]

Common Mistakes:

• Expecting undefined if user exists
• Confusing null with undefined
• Assuming error thrown instead of null result

4. You wrote this test code but it throws an error:

const result = await server.executeOperation({ query: `mutation { addUser(name: "Bob") { id } }` });

What is the most likely cause?

medium

A. The mutation name is incorrect or not defined in schema

B. The query should be a GET request, not mutation

C. executeOperation cannot run mutations

D. Missing await keyword before server.executeOperation

Solution

1. Step 1: Check mutation usage in test

   executeOperation supports mutations, so that is not the issue.

2. Step 2: Verify mutation name and schema

   If mutation name addUser is not defined in the schema, the server throws an error.

3. Final Answer:

   The mutation name is incorrect or not defined in schema -> Option A

4. Quick Check:

   Mutation must exist in schema to run [OK]

Hint: Check mutation name matches schema exactly [OK]

Common Mistakes:

• Thinking executeOperation can't run mutations
• Forgetting to await executeOperation
• Confusing query and mutation types

5. You want to write an integration test that checks if a mutation correctly adds a user and then a query fetches that user. Which sequence correctly tests this on a GraphQL test server?

hard

A. Run mutation with executeOperation, then run query with executeOperation, check query result matches mutation data

B. Run query first, then mutation, then check mutation result

C. Run mutation and query in parallel without waiting, then check results

D. Only run mutation; query testing is unnecessary in integration tests

Solution

1. Step 1: Understand integration test flow

   Integration tests verify that mutations affect data and queries reflect those changes.

2. Step 2: Correct test sequence

   First run mutation to add user, then query to fetch user, then compare results to confirm correctness.

3. Final Answer:

   Run mutation with executeOperation, then run query with executeOperation, check query result matches mutation data -> Option A

4. Quick Check:

   Mutation then query to verify changes [OK]

Hint: Test mutation first, then query to confirm data change [OK]

Common Mistakes:

• Running query before mutation
• Running mutation and query in parallel without order
• Skipping query test after mutation