Mocking resolvers in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this mocked resolver query?

Given this GraphQL schema and mocked resolver, what will be the output of the query?

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

type User {
  id: ID!
  name: String
  age: Int
}

// Mock resolver for user
const mocks = {
  Query: () => ({
    user: (_parent, args) => ({
      id: args.id,
      name: "Alice",
      age: 30
    })
  })
};

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

GraphQL

const mocks = {
  Query: () => ({
    user: (_parent, args) => ({
      id: args.id,
      name: "Alice",
      age: 30
    })
  })
};

A { "data": { "user": { "id": "123", "name": "Alice", "age": 30 } } }

B { "data": { "user": { "id": null, "name": "Alice", "age": 30 } } }

C { "data": { "user": { "id": "123", "name": null, "age": 30 } } }

D { "data": { "user": null } }

💡 Hint

Look at how the id is returned from the args in the resolver.

The mocked resolver returns the user object with id taken from the query argument id. So the output includes "id": "123" along with the fixed name and age.

📝 Syntax

intermediate

Which mocked resolver code snippet has a syntax error?

Identify the option that contains a syntax error in the mocked resolver definition.

A const mocks = { Query: () => ({ user: (_parent, args) => ({ id: args.id, name: "Bob" }) }) };

B const mocks = { Query: () => ({ user: (_parent, args) => { id: args.id, name: "Bob" } }) };

C ;} )} )} "boB" :eman ,di.sgra :di {( >= )sgra ,tnerap_( :resu {( >= )( :yreuQ { = skcom tsnoc

D onst mocks = { Query: () => ({ user: (_parent, args) => ({ id: args.id, name: "Bob" }) }) };

💡 Hint

Check the arrow function syntax and object return syntax carefully.

Option B uses curly braces without a return statement inside the arrow function, so it does not return an object but a block, causing a syntax error or unexpected behavior.

❓ optimization

advanced

How to optimize mocking multiple similar resolvers?

You have many similar resolvers returning user data with different IDs. Which approach optimizes mocking these resolvers efficiently?

A Mock only one user and return null for others.

B Write separate resolver functions for each user ID manually.

C Hardcode a single user object and ignore the <code>id</code> argument in all resolvers.

D Use a generic resolver function that returns user data based on the <code>id</code> argument dynamically.

💡 Hint

Think about how to reuse code and handle dynamic input.

Using a generic resolver that reads the id argument and returns corresponding data dynamically avoids repetitive code and scales better.

🔧 Debug

advanced

Why does this mocked resolver return null for a field?

Given this mocked resolver snippet, why does the email field return null in the query result?

const mocks = {
  User: () => ({
    id: "1",
    name: "Eve"
  })
};

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

A The <code>email</code> field is not defined in the mocked resolver, so it returns null by default.

B The resolver returns an error causing the <code>email</code> field to be null.

C The query is malformed and does not request the <code>email</code> field properly.

D The schema does not include the <code>email</code> field in the User type.

💡 Hint

Check which fields the mock resolver explicitly returns.

Mocked resolvers return null for any fields not explicitly defined in the mock. Since email is missing, it returns null.

🧠 Conceptual

expert

What is the main benefit of mocking resolvers in GraphQL development?

Choose the best explanation for why developers use mocked resolvers during GraphQL API development.

A To automatically generate database schemas from GraphQL queries.

B To permanently replace the backend with static data for production use.

C To simulate API responses without needing a real backend, enabling frontend development and testing independently.

D To enforce strict type checking on client-side queries.

💡 Hint

Think about development workflow and decoupling frontend from backend.

Mocking resolvers allows frontend developers to work with expected data shapes without waiting for backend implementation, speeding up development and testing.