GraphQL has been around since 2012, yet many developers haven’t had the chance to work with it. Personally, I’ve been using GraphQL on and off for several years, both in personal and professional projects. Recently, I’ve been diving deeper into it again-and I’ve fallen in love with it all over.

While implementing a few queries and mutations, I started to wonder: how could I effectively test my GraphQL implementation? Specifically, how could I send queries and mutations with a GraphQL client directly from my tests to ensure everything works as expected?

After some experimentation, I found a solution I’m excited to share: combining specifications with Reqnroll, the .NET WebApplicationFactory , and the Strawberry Shake GraphQL client to test a Hot Chocolate GraphQL server . This approach not only works seamlessly but also results in clean, readable specifications.

In this article, I’ll guide you through the process of setting up these tests, allowing you to test your own GraphQL server with clarity and confidence. Let’s get started!

GraphQL, a very short introduction

This article is not intended to explain what GraphQL is, but here’s a very short introduction: GraphQL is a query language and a runtime that lets clients fetch exactly the data they need, making it incredibly flexible and efficient. It supports queries, mutations, and subscriptions — where queries and mutations can roughly be compared to GET and POST methods in REST.

One of the big differences between GraphQL and REST is that with GraphQL, you can specify exactly what data you need. This eliminates the problem of under-fetching (not enough data) or over-fetching (too much unnecessary data), making GraphQL an excellent choice for optimizing data transfer.

An example query in the GraphQL query language, with the result in JSON.

Figure 1: “An example query in the GraphQL query language, with the result in JSON.”

This query requests a list of books, and from each book the fields title, auhor and the ISBN number.

Why testing GraphQL, and why with specifications

  • Is authentication and authorization configured correctly?
  • Do resolvers work as expected and deliver the correct information?
  • Are all data flows implemented as required?

The above specification illustrates the use case depicted in the GraphQL query shown in figure 1. It represents a request for a list of books, retrieving specific fields such as the title, author, and ISBN number for each book.

Overview of tools and techniques

Example Application: A Simple Bookstore API

  • A list of books, each with details such as title, author, and publication year.
  • Authorization and authentication mechanisms to control access to certain actions.
  • The ability to add new books, but only if the user is logged in as a store owner.

Writing the first specification

The specifications are bound to code to make the scenarios testable. While diving into how this binding works is beyond the scope of this article, here’s a screenshot of how the specifications are connected to the underlying code:

Figure 2: “Test results in JetBrains Rider”

Executing GraphQL queries in tests

To execute GraphQL queries in the test project, a few steps are required. First, you need to create a query in the GraphQL directory, which is automatically created when installing the Strawberry Shake client.

For the specification above, the query is stored in the file BookQueries.graphql , and it looks like this:

After saving the GraphQL file and building the test project, the Strawberry Shake client generates the code for a new client, after which the query can be executed. In this project, the code to execute the query looks like this:

Figure 3: “Test results in JetBrains Rider”

Conclusion

Links

key take-aways

Thanks for taking the time to dive into this article! Before you go, here are my three key takeaways from testing GraphQL with specifications using Reqnroll:

Met Jacob in gesprek?