Integration tests with test server in GraphQL - Deep Dive

Overview - Integration tests with test server

What is it?

Integration tests with a test server check how different parts of a GraphQL application work together. Instead of testing pieces alone, these tests run the whole system or big parts of it, including the server and database. This helps find problems that only appear when components interact. It uses a special test server that mimics the real one but is safe for testing.

Why it matters

Without integration tests using a test server, bugs that happen only when parts work together can go unnoticed. This can cause crashes or wrong data in real use, hurting users and trust. Integration tests catch these issues early, saving time and money. They make sure the whole system behaves as expected, not just isolated parts.

Where it fits

Before learning this, you should know basic GraphQL queries and mutations, and how unit tests work. After mastering integration tests with a test server, you can learn about end-to-end testing and continuous integration pipelines to automate testing in real projects.

Mental Model

Core Idea

Integration tests with a test server run the full GraphQL system in a safe environment to check if all parts work together correctly.

Think of it like...

It's like test-driving a car on a closed track before selling it, to make sure the engine, brakes, and steering all work together smoothly.

┌─────────────────────────────┐
│       Test Server Setup      │
│ ┌───────────────┐           │
│ │ GraphQL Server│           │
│ └──────┬────────┘           │
│        │                    │
│ ┌──────▼───────┐           │
│ │  Database    │           │
│ └──────────────┘           │
│                             │
│  Integration Test Scripts    │
│  ────────────────────────>  │
│  Send queries/mutations      │
│  Check responses             │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding GraphQL Basics

Concept: Learn what GraphQL is and how queries and mutations work.

GraphQL is a way to ask for data from a server using queries and to change data using mutations. It lets clients specify exactly what data they want. For example, a query can ask for a user's name and email, and the server returns just that.

Result

You can write simple GraphQL queries and understand their responses.

Knowing how GraphQL works is essential before testing it, because tests send queries and mutations to the server.

2

Foundation

Basics of Testing GraphQL

Concept: Learn how to write simple tests for GraphQL queries and mutations.

Testing GraphQL means sending queries or mutations and checking if the server returns the expected data. Unit tests check small parts like resolvers, but they don't test the whole system working together.

Result

You can write tests that check if a query returns the right data for a fixed input.

Understanding unit tests helps you see why integration tests are needed to check the whole system.

3

Intermediate

Setting Up a Test Server

🤔Before reading on: do you think a test server uses the real database or a separate one? Commit to your answer.

Concept: Learn how to create a test server that runs your GraphQL API with a test database.

A test server is a version of your GraphQL server that runs only during tests. It uses a separate test database or an in-memory database to avoid changing real data. You start this server before tests and stop it after. This setup lets tests send real queries and mutations to a live server.

Result

You have a running test server that accepts GraphQL requests and uses test data.

Knowing how to isolate tests with a test server prevents tests from affecting real data and each other.

4

Intermediate

Writing Integration Tests with Test Server

🤔Before reading on: do you think integration tests check only one resolver or multiple components working together? Commit to your answer.

Concept: Learn to write tests that send real GraphQL requests to the test server and check full responses.

Integration tests send queries or mutations to the test server's endpoint, just like a real client. They check the full response, including data and errors. These tests verify that resolvers, database access, and middleware all work together correctly.

Result

Tests confirm that the GraphQL API behaves correctly when used as a whole.

Understanding that integration tests cover multiple components working together helps catch bugs missed by unit tests.

5

Intermediate

Managing Test Data and Cleanup

🤔Before reading on: do you think test data should persist between tests or reset each time? Commit to your answer.

Concept: Learn how to prepare and clean test data to keep tests independent and reliable.

Each test should start with a known database state. You can insert test data before tests and remove it after, or use transactions that rollback changes. This ensures tests don't affect each other and results are consistent.

Result

Tests run reliably with fresh data every time.

Knowing how to manage test data prevents flaky tests and hidden bugs caused by leftover data.

6

Advanced

Mocking External Services in Integration Tests

🤔Before reading on: do you think integration tests should call real external APIs or mock them? Commit to your answer.

Concept: Learn to replace real external services with mocks during integration tests to keep tests fast and reliable.

If your GraphQL server calls other APIs or services, integration tests can use mocks to simulate their responses. This avoids slow or unreliable tests caused by network calls and lets you test error cases easily.

Result

Integration tests run quickly and predictably without depending on external services.

Understanding when and how to mock external calls keeps integration tests focused and stable.

7

Expert

Parallelizing Integration Tests Safely

🤔Before reading on: do you think running integration tests in parallel can cause conflicts? Commit to your answer.

Concept: Learn techniques to run integration tests at the same time without interfering with each other.

Running tests in parallel speeds up testing but can cause conflicts if tests share the same database or server. Solutions include using separate test databases per test, unique data namespaces, or containerized test servers. This ensures tests don't overwrite each other's data.

Result

Integration tests run faster and remain reliable even when executed simultaneously.

Knowing how to isolate parallel tests prevents subtle bugs and speeds up development cycles.

Under the Hood

The test server runs a full instance of the GraphQL API, including schema, resolvers, and database connections. When a test sends a query, the server parses it, executes resolvers in order, accesses the test database, and returns a response. Middleware and error handling also run as in production. This simulates real client-server interaction in a controlled environment.

Why designed this way?

Integration tests with a test server were designed to catch bugs that unit tests miss, especially those caused by interactions between components. Using a separate test server and database avoids risking real data and allows tests to run in isolation. Alternatives like mocking everything miss integration bugs, while testing on production is unsafe.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Test Script   │──────▶│ Test GraphQL  │──────▶│ Test Database │
│ sends query  │       │ Server        │       │ (isolated)    │
└───────────────┘       └───────────────┘       └───────────────┘
       ▲                      │                        ▲
       │                      │                        │
       └──────────────────────┴────────────────────────┘
                 Receives response with data/errors

Myth Busters - 4 Common Misconceptions

Quick: Do integration tests replace the need for unit tests? Commit to yes or no.

Common Belief: Integration tests are enough; unit tests are not needed.

Reality: Integration tests complement but do not replace unit tests. Unit tests catch small bugs quickly and help isolate problems.

Why it matters: Skipping unit tests can make debugging harder and slow down development because integration tests are slower and less focused.

Quick: Should integration tests use the real production database? Commit to yes or no.

Common Belief: Integration tests should run against the real production database for accuracy.

Reality: Integration tests must use a separate test database to avoid corrupting real data and to keep tests repeatable.

Why it matters: Using production data risks data loss, privacy issues, and unreliable tests due to changing data.

Quick: Do integration tests always run slower than unit tests? Commit to yes or no.

Common Belief: Integration tests are always slow and should be minimized.

Reality: While integration tests are slower than unit tests, good setup, parallelization, and mocking can make them efficient.

Why it matters: Believing integration tests must be slow can lead to skipping them, increasing risk of bugs in production.

Quick: Can integration tests catch UI bugs? Commit to yes or no.

Common Belief: Integration tests with a test server catch all bugs, including UI problems.

Reality: Integration tests focus on backend and API interactions; UI bugs require separate end-to-end tests.

Why it matters: Relying only on integration tests can miss user interface issues, leading to poor user experience.

Expert Zone

1

Integration tests often reveal timing and concurrency issues that unit tests miss, especially with asynchronous resolvers.

2

Test servers can be configured to mimic production environment variables and middleware, but subtle differences can still cause bugs to appear only in production.

3

Managing schema changes during integration tests requires careful versioning to avoid breaking tests unexpectedly.

When NOT to use

Integration tests with a test server are not ideal for testing UI behavior or user workflows; use end-to-end testing tools instead. For very small isolated logic, unit tests are faster and simpler. When external dependencies are unstable, consider contract testing or mocking instead.

Production Patterns

In real projects, integration tests run automatically in CI pipelines on every code push. Test servers often run in containers with isolated databases. Tests seed data before running and clean up after. Mocks are used for third-party APIs. Parallel test execution is common to reduce feedback time.

Connections

Unit Testing

Builds-on

Understanding unit tests helps grasp why integration tests are needed to check how units work together.

Continuous Integration (CI)

Builds-on

Integration tests with test servers are key steps in CI pipelines to ensure code changes don't break the system.

Systems Engineering

Same pattern

Integration testing in software parallels systems integration in engineering, where components are tested together to ensure overall function.

Common Pitfalls

#1 Running integration tests against the production database.

Wrong approach:

const testServer = createTestServer({ databaseUrl: 'https://prod-db.example.com' });

Correct approach:

const testServer = createTestServer({ databaseUrl: 'postgres://localhost/test-db' });

Root cause:

Confusing environment configurations and not isolating test data from production.

#2 Not cleaning up test data between tests causing flaky results.

Wrong approach:

test('create user', async () => { await testServer.mutate(createUser); });
test('get user', async () => { const user = await testServer.query(getUser); expect(user).toBeDefined(); });

Correct approach:

beforeEach(async () => { await resetTestDatabase(); });
test('create user', async () => { await testServer.mutate(createUser); });
test('get user', async () => { const user = await testServer.query(getUser); expect(user).toBeDefined(); });

Root cause:

Assuming tests run in isolation without resetting shared state.

#3 Calling real external APIs in integration tests causing slow and unreliable tests.

Wrong approach:

const response = await testServer.query(realExternalApiQuery);

Correct approach:

mockExternalApiResponse();
const response = await testServer.query(mockedApiQuery);

Root cause:

Not isolating tests from external dependencies.

Key Takeaways

Integration tests with a test server check how all parts of a GraphQL system work together in a safe, controlled environment.

They catch bugs that unit tests miss by running real queries and mutations against a live server and test database.

Proper setup includes isolating test data, managing test server lifecycle, and mocking external services when needed.

Running tests in parallel requires careful isolation to avoid conflicts and speed up feedback.

Integration tests are essential in professional workflows and continuous integration to ensure system reliability.

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