test.go

    RunParallel(t, TestCase{
        Steps: []TestStep{
            {
                Query: `
                query getWorksheet($id: ObjectId!) {
                    worksheet(id: $id) {
                        id
                        label
                        name
                    }
                }`,
                Variables: map[string]interface{}{
                    "id": "40000057",
                },
                Check: ComposeCheckFunc(
                    CheckResponse("worksheet.label", "Worksheet for 101 First Board"),
                    CheckResponse("worksheet.name", "Worksheet for 101 First Board"),
                ),
            },
        },
    })

unit-test-resolver.md

I don't have a great example that is really setup to share.

The biggest issue with this is actually that usually the resolver needs quite a bit of mock behind it to actually keep the test remotely close to a unit test.

Most of what we've done is setup a framework for non Subscription queries, is setup a framework where the test specifies a graphql query to be run and then does some output validation.

For simpler cases we have a more structured test-case framework that builds on top of the general framework.

For Subscriptions those are a little trickier. We use a fake http connection that gets converted into a net.Pipe() in the unit test framework. Then have two handlers because we use subscriptions in two different ways.

One of those handlers will return a channel that you can read to get messages from and the tests will use these to interleave reads from the subscription and other system updates for which we would expect a message on the subscription.

The other handler makes the Subscription call and then reads messages until the operation completes, and then returns all of those results in a slice for validation.

In total we've got about 5k lines of schema, and 15k lines of resolvers (not counting the data-structures which are hand written in another module rather than generated, and a lot of the heaviest lifting is calling out to other modules) and about 30k lines of tests that work with the resolvers (and obviously more tests that live in the other modules that the resolvers call out to).