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);const users = [{id: 1, name: "Alice"}, {id: 2, name: "Bob"}]; const resolver = { Query: { users: () => users } }; const result = resolver.Query.users(); console.log(result.length);
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.
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);const resolver = { Query: { user: (parent, args) => { return {id: args.id, name: "Test User"}; } } }; const result = resolver.Query.user(null, {id: 1}); console.log(result);
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.
You want to optimize a resolver unit test that fetches user data from a mock database. Which approach reduces test runtime most effectively?
Think about what makes tests fast and reliable.
Using a mock function returning static data avoids delays and external dependencies, speeding up tests.
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?
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".
Why do developers mock external services or databases when writing resolver unit tests?
Think about what makes unit tests reliable and fast.
Mocking isolates the resolver so tests focus only on its logic, avoiding unpredictable external factors.