Unit Testing for Resolvers

[KoichiKiyokawa]

Firstly, I want to express my gratitude for all the work you've put into Pothos.

I have a question about unit testing for resolvers. Is there a way to accomplish this? Here is an example of what I'm trying to test:

builder.queryField("users", (t) =>
  t.field({
    type: [User],
    // 👇👇👇 I want to test this.
    resolve(_parent, _args, ctx) {
      return ctx.db.user.findMany();
    },
  })
);

One method I considered was to extract the resolver function,

builder.queryField("users", (t) =>
  t.field({
    type: [User],
    resolve,
  })
);

// 👇👇👇 Extract
function resolve(_parent, _args, ctx) {
    return ctx.db.user.findMany();
},

but this loses type inference.

I understand that it's possible to perform E2E testing by sending queries to the GraphQL server. However, I also recognize that this approach tends to be costly and can often lead to instability.

By way of comparison, the library tRPC provides a createCaller method to run each procedure, which is potentially similar to a resolver. An example can be seen here:
https://github.com/trpc/examples-next-prisma-starter/blob/dc695cd820ea5b6560fefab9c0689fbc85d0a378/src/server/routers/post.test.ts#L10

Do you have any advice on how I could approach this in Pothos? Thank you in advance.

[hayes]

My general approach to testing GraphQL apis is to not unit test resolvers, because things generally fall into 2 categories:

1. The resolver is very simple, and it makes more sense to test it as part of a GraphQL query
2. The logic is complex, and the complex parts of the resolver should be moved into a function that can be tested independently, and the resolver is just a wrapper that calls your logic with the right arguments

That being said, it's pretty easy to get a resolver from your schema to test. Here is an example:

import {
  GraphQLFieldResolver,
  GraphQLObjectType,
  GraphQLSchema,
  defaultFieldResolver,
} from 'graphql';

const schema = builder.toSchema()

const resolver = getResolver(schema, 'Query', 'users')

export function getResolver(
  schema: GraphQLSchema,
  typeName: string,
  fieldName: string,
): GraphQLFieldResolver<unknown, unknown> {
  const type = schema.getType(typeName);

  if (!(type instanceof GraphQLObjectType)) {
    throw new TypeError(`Type ${typeName} is not an object type`);
  }

  const field = type.getFields()[fieldName];

  if (!field) {
    throw new Error(`Field ${field} not found on type ${type}`);
  }

  return field.resolve ?? defaultFieldResolver;
}

This gets you the resolver along with any wrapping logic Pothos applies (eg auth checks). You can also get the unwrapped resolver from the fields extensions

export function getUnwrappedResolver(
  schema: GraphQLSchema,
  typeName: string,
  fieldName: string,
): GraphQLFieldResolver<unknown, unknown> {
  const type = schema.getType(typeName);

  if (!(type instanceof GraphQLObjectType)) {
    throw new TypeError(`Type ${typeName} is not an object type`);
  }

  const field = type.getFields()[fieldName];

  if (!field) {
    throw new Error(`Field ${field} not found on type ${type}`);
  }

  return field.extensions.pothosConfig.resolve ?? defaultFieldResolver
}

[KoichiKiyokawa]

Thank you for your detailed explanation! I understand that unit testing for resolvers themselves is not particularly useful.
The method you taught for extracting resolvers from the schema is very cool and has been extremely helpful to me..

[awinograd]

Is there a way to make the return type safe? i.e. replace the unknowns with some generic based on the type of builder?

[hayes]

Not really. There's a lot of complexity in what resolvers are allowed to return, and the types allowed to be returned by a resolver when defining a field may not be the same as what is actually returned by the resolver in the schema depending on what plugins are being used. It's possible to re-create the expected return type by providing the type of the field for most fields, but again, this isn't reliable when using various plugins. Unknown is really the most correct type for most use cases.

I really would encourage executing queries against your schema directly, or extracting important business logic into functions that can be tested outside of Pothos

[awinograd]

Ok, thanks for your thoughts here @hayes ! Much appreciated as always