Resolver unit tests in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the output of this resolver unit test?

Given a GraphQL resolver that returns a list of users, what will be the result of this unit test?

const users = [{id: 1, name: "Alice"}, {id: 2, name: "Bob"}];

const resolver = {
  Query: {
    users: () => users
  }
};

// Test
const result = resolver.Query.users();
console.log(result.length);

GraphQL

const users = [{id: 1, name: "Alice"}, {id: 2, name: "Bob"}];

const resolver = {
  Query: {
    users: () => users
  }
};

const result = resolver.Query.users();
console.log(result.length);

A 0

B undefined

C 2

D 1

💡 Hint

Think about how many user objects are in the array returned by the resolver.

The resolver returns the array of users with two objects, so the length is 2.

📝 Syntax

intermediate

Which option causes a syntax error in this resolver test?

Identify which resolver unit test code snippet will cause a syntax error.

const resolver = {
  Query: {
    user: (parent, args) => {
      return {id: args.id, name: "Test User"};
    }
  }
};

// Test call
const result = resolver.Query.user(null, {id: 1});
console.log(result);

GraphQL

const resolver = {
  Query: {
    user: (parent, args) => {
      return {id: args.id, name: "Test User"};
    }
  }
};

const result = resolver.Query.user(null, {id: 1});
console.log(result);

A const result = resolver.Query.user(null, id: 1); console.log(result);

B const result = resolver.Query.user(null, {id: 1}); console.log(result);

C ;)tluser(gol.elosnoc ;)}1 :di{ ,llun(resu.yreuQ.revloser = tluser tsnoc

D onst result = resolver.Query.user(null, {id: 1}); console.log(result);

💡 Hint

Look carefully at how the arguments are passed to the resolver function.

Option A passes arguments incorrectly without braces around the object, causing a syntax error.

❓ optimization

advanced

Which option optimizes resolver unit test performance best?

You want to optimize a resolver unit test that fetches user data from a mock database. Which approach reduces test runtime most effectively?

A Use a mock function that returns a static user object immediately.

B Call the real database in each test to ensure data accuracy.

C Use a delayed promise to simulate network latency in tests.

D Run tests sequentially with real database calls.

💡 Hint

Think about what makes tests fast and reliable.

Using a mock function returning static data avoids delays and external dependencies, speeding up tests.

🔧 Debug

advanced

Why does this resolver unit test fail?

Consider this resolver and test code:

const resolver = {
  Query: {
    user: (parent, args) => {
      if (!args.id) throw new Error("ID required");
      return {id: args.id, name: "User" + args.id};
    }
  }
};

// Test
try {
  resolver.Query.user(null, {});
} catch (e) {
  console.log(e.message);
}

What is the output of the test?

A TypeError

B undefined

C "Userundefined"

D "ID required"

💡 Hint

Check what happens when args.id is missing.

The resolver throws an error if args.id is missing, so the catch block logs "ID required".

🧠 Conceptual

expert

What is the main benefit of mocking dependencies in resolver unit tests?

Why do developers mock external services or databases when writing resolver unit tests?

A To ensure the resolver always connects to the real database.

B To isolate the resolver logic and test it without external side effects.

C To slow down tests and simulate real network delays.

D To increase the complexity of tests by adding more dependencies.

💡 Hint

Think about what makes unit tests reliable and fast.

Mocking isolates the resolver so tests focus only on its logic, avoiding unpredictable external factors.

Practice

1. What is the main purpose of a resolver unit test in GraphQL?

easy

A. To verify the database connection settings

B. To test the entire GraphQL schema at once

C. To check if a resolver returns the correct data

D. To style the GraphQL playground interface

Solution

1. Step 1: Understand resolver role

   Resolvers are functions that fetch and return data for GraphQL queries.

2. Step 2: Purpose of unit tests

   Unit tests check small parts of code, here specifically if resolvers return correct data.

3. Final Answer:

   To check if a resolver returns the correct data -> Option C

4. Quick Check:

   Resolver unit tests = check resolver output [OK]

Hint: Resolvers return data; tests check if data is correct [OK]

Common Mistakes:

• Confusing unit tests with integration tests
• Thinking tests check UI or styling
• Assuming tests check database setup

2. Which syntax correctly defines a simple resolver unit test using Jest?

easy

A. describe('Test', () => { it('checks resolver', () => { expect(resolver()).toBe(data); }); });

B. test('Test', () => { describe('checks resolver', () => { expect(resolver()).toBe(data); }); });

C. it('Test', () => { expect(resolver()).toBe(data); }); describe('checks resolver', () => {});

D. expect('Test', () => { it('checks resolver', () => { resolver(); }); });

Solution

1. Step 1: Identify Jest test structure

   Jest uses describe to group tests and it or test for individual tests.

2. Step 2: Check correct nesting and syntax

   describe('Test', () => { it('checks resolver', () => { expect(resolver()).toBe(data); }); }); correctly nests it inside describe and uses expect properly.

3. Final Answer:

   describe('Test', () => { it('checks resolver', () => { expect(resolver()).toBe(data); }); }); -> Option A

4. Quick Check:

   describe + it + expect = correct test syntax [OK]

Hint: Use describe for groups, it for tests, expect for checks [OK]

Common Mistakes:

• Swapping describe and it blocks
• Missing expect or incorrect nesting
• Using expect without a matcher

3. Given this resolver and test code, what will the test output be?

const resolver = () => ({ id: 1, name: 'Alice' });

describe('User resolver', () => {
  it('returns correct user', () => {
    expect(resolver()).toEqual({ id: 1, name: 'Alice' });
  });
});

medium

A. Test throws runtime error

B. Test fails due to wrong object

C. Syntax error in test code

D. Test passes successfully

Solution

1. Step 1: Analyze resolver output

   The resolver returns an object { id: 1, name: 'Alice' } exactly.

2. Step 2: Check test expectation

   The test expects the same object using toEqual, which compares object values deeply.

3. Final Answer:

   Test passes successfully -> Option D

4. Quick Check:

   Exact object match = test passes [OK]

Hint: toEqual checks deep equality; objects must match exactly [OK]

Common Mistakes:

• Confusing toBe with toEqual for objects
• Expecting test to fail with correct data
• Misreading object properties

4. Identify the error in this resolver unit test code:

describe('Test resolver', () => {
  it('returns data', () => {
    expect(resolver).toBe(data);
  });
});

medium

A. No error; code is correct

B. Missing parentheses to call resolver function

C. Wrong matcher; should use toEqual instead of toBe

D. Incorrect use of describe block

Solution

1. Step 1: Check resolver usage

   The test uses resolver without parentheses, so it tests the function itself, not its return value.

2. Step 2: Correct function call

   To test the returned data, the resolver must be called as resolver().

3. Final Answer:

   Missing parentheses to call resolver function -> Option B

4. Quick Check:

   Call resolver() to get data, not resolver [OK]

Hint: Call functions with () to test their output [OK]

Common Mistakes:

• Forgetting to call the resolver function
• Confusing toBe and toEqual for objects
• Misplacing describe and it blocks

5. You want to test a resolver that fetches a user by ID from a mock database. Which approach best ensures your unit test is isolated and reliable?

hard

A. Mock the database call inside the resolver test to return fixed data

B. Connect to the real database and fetch actual user data

C. Skip testing the resolver and test only the database separately

D. Write tests that depend on network availability

Solution

1. Step 1: Understand unit test isolation

   Unit tests should test one part only, without relying on external systems like databases.

2. Step 2: Use mocking for database calls

   Mocking replaces real database calls with fixed data, making tests fast and reliable.

3. Final Answer:

   Mock the database call inside the resolver test to return fixed data -> Option A

4. Quick Check:

   Mock external calls for isolated unit tests [OK]

Hint: Mock external dependencies to isolate resolver tests [OK]

Common Mistakes:

• Using real database in unit tests
• Skipping resolver tests entirely
• Writing flaky tests depending on network