Integration tests with test server in GraphQL - Mini Project: Build & Apply
Start learning this pattern below
Jump into concepts and practice - no test required
Create a GraphQL schema string called typeDefs that defines a Book type with fields id (ID!), title (String!), and author (String!). Also define a Query type with a field book that takes an id argument of type ID! and returns a Book.
Use backticks to create a multi-line string. Define the Book type and Query type exactly as described.
Create a constant called resolvers that defines a Query resolver with a book function. This function takes parent, args, and returns a book object with id, title, and author fields. Return the book with id equal to args.id, title as "Test Book", and author as "John Doe".
Define the resolvers object with a Query field. The book resolver returns a fixed book object using args.id.
Create a constant called server that is a new ApolloServer instance. Pass typeDefs and resolvers as options to the constructor.
Import ApolloServer and create a new instance with the schema and resolvers.
Write an async function called testBookQuery. Inside, call server.executeOperation with a query string that requests book(id: "1") and asks for id, title, and author. Await the result and assign it to a variable called response. Then check that response.data.book.id equals "1", response.data.book.title equals "Test Book", and response.data.book.author equals "John Doe".
Use server.executeOperation with a query string. Check the response data fields for expected values.
Practice
Solution
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.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.Final Answer:
To run queries and mutations safely without affecting real data -> Option BQuick Check:
Test server = safe testing environment [OK]
- Thinking test server speeds up production
- Confusing test server with permanent database replacement
- Assuming test server auto-generates data
Solution
Step 1: Recall Apollo Server setup
Apollo Server requires creating an instance with typeDefs and resolvers, then calling start() before listen().Step 2: Identify correct method to start server
The correct method to start the server is await server.start(); before running listen().Final Answer:
const server = new ApolloServer({ typeDefs, resolvers }); await server.start(); -> Option DQuick Check:
Use server.start() before listen() [OK]
- Calling listen() without starting server
- Using incorrect constructor syntax
- Assuming server.run() or startServer() exist
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"?Solution
Step 1: Understand executeOperation result
executeOperation returns an object with data containing the query result if successful.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".Final Answer:
"Alice" -> Option CQuick Check:
Query result matches user name "Alice" [OK]
- Expecting undefined if user exists
- Confusing null with undefined
- Assuming error thrown instead of null result
const result = await server.executeOperation({ query: `mutation { addUser(name: "Bob") { id } }` });What is the most likely cause?Solution
Step 1: Check mutation usage in test
executeOperation supports mutations, so that is not the issue.Step 2: Verify mutation name and schema
If mutation name addUser is not defined in the schema, the server throws an error.Final Answer:
The mutation name is incorrect or not defined in schema -> Option AQuick Check:
Mutation must exist in schema to run [OK]
- Thinking executeOperation can't run mutations
- Forgetting to await executeOperation
- Confusing query and mutation types
Solution
Step 1: Understand integration test flow
Integration tests verify that mutations affect data and queries reflect those changes.Step 2: Correct test sequence
First run mutation to add user, then query to fetch user, then compare results to confirm correctness.Final Answer:
Run mutation with executeOperation, then run query with executeOperation, check query result matches mutation data -> Option AQuick Check:
Mutation then query to verify changes [OK]
- Running query before mutation
- Running mutation and query in parallel without order
- Skipping query test after mutation
