Resolver unit tests in GraphQL - Step-by-Step Execution

Concept Flow - Resolver unit tests

Write Resolver Function

↓

Write Unit Test for Resolver

↓

Mock Dependencies (DB, APIs)

↓

Run Test

↓

Check Output vs Expected

↓

Pass?

No→Fix Resolver or Test

Yes↓

Done

This flow shows writing a resolver, creating a test with mocks, running it, and checking if output matches expected results.

Execution Sample

GraphQL

const resolver = (parent, args, context) => {
  return context.db.getUser(args.id);
};

// Test
const mockDb = { getUser: (id) => ({ id, name: 'Alice' }) };
const result = resolver(null, { id: 1 }, { db: mockDb });

This code defines a resolver that fetches a user by id from a mocked database and runs a test to check the returned user.

Execution Table

Step	Action	Input	Mock Used	Output	Check
1	Call resolver	args.id=1	mockDb.getUser	Calls mockDb.getUser(1)	N/A
2	mockDb.getUser called	id=1	N/A	{ id: 1, name: 'Alice' }	N/A
3	Resolver returns	N/A	N/A	{ id: 1, name: 'Alice' }	Output matches expected user object
4	Test assertion	Output	N/A	Pass	Output equals expected result

💡 Test passes because resolver output matches expected mocked user data

Variable Tracker

Variable	Start	After Call	Final
args	{ id: 1 }	{ id: 1 }	{ id: 1 }
context.db	mockDb object	mockDb object	mockDb object
result	undefined	{ id: 1, name: 'Alice' }	{ id: 1, name: 'Alice' }

Key Moments - 2 Insights

Why do we use a mock database instead of the real one in tests?

Using a mock database isolates the resolver logic and ensures tests run fast and reliably without depending on real database state, as shown in execution_table step 2.

What happens if the resolver returns data different from the expected output?

The test assertion in execution_table step 4 would fail, indicating a bug in the resolver or test setup that needs fixing.

Visual Quiz - 3 Questions

Look at the execution table, what is the output after the resolver calls mockDb.getUser?

A { id: 1, name: 'Alice' }

B undefined

C null

D { id: 2, name: 'Bob' }

💡 Hint

Check execution_table row 2 under Output column

At which step does the test confirm the output matches the expected result?

A Step 3

B Step 4

C Step 1

D Step 2

💡 Hint

Look at execution_table row 4 under Check column

If the mockDb.getUser returned null, how would the test result change?

A Test would pass as usual

B Test would error out immediately

C Test would fail because output differs from expected

D Test would skip assertion

💡 Hint

Consider the importance of matching output in execution_table step 4

Concept Snapshot

Resolver unit tests:
- Write resolver function accessing data
- Mock dependencies like databases
- Run resolver with test inputs
- Check output matches expected
- Fix code if test fails
- Ensures resolver logic correctness

Full Transcript

Resolver unit tests involve writing a resolver function that fetches data, then creating a test that calls this resolver with specific inputs. Instead of using a real database, a mock database is used to isolate the resolver logic and keep tests fast and reliable. The test runs the resolver, captures the output, and compares it to the expected result. If the output matches, the test passes; otherwise, it fails and requires fixing the resolver or test. This process ensures the resolver works correctly in isolation.