Automatic Testing for GraphQL APIs – InApps 2022

GraphQL is quickly becoming a preferred alternative to the traditional REST architecture API developers have been using for many years. It gives front-end developers the ability to query only what they need through a single endpoint. Because of its numerous benefits, back-end developers are adapting industry-standard strategies to ensure they build fluent and scalable APIs in GraphQL.

One of those standards is having a well-tested GraphQL API. In this post, we will take a look at how to test GraphQL APIs and automate the testing process with CircleCI.

To follow along with this post, you will need the following already set up:

• Basic knowledge of GraphQL (see our recent post, Introduction to GraphQL)
• Node.js installed on your system (you can confirm this by running the node -v command on your terminal to print out the version of Node.js installed)
• Git installed on your system (you can confirm this by running the git command on your terminal; this should print out available git commands)
• A GitHub account
• A CircleCI account

Creating the GraphQL Server

Our first task is to set up a simple GraphQL server using Node.js. Create a folder for the project by running the following command:

Now go into the project root by running this:

and then run the following command to quickly set up your package.json file:

This will quickly scaffold a basic package.json file.

To set up our GraphQL server, we will need the following packages:

* express: to create our ExpressJS node application
* graphql: the GraphQL npm package for Node.js
* express-graphql: ExpressJS middleware for GraphQL

Run the following command to install these packages:

Perfect!

Once these packages are installed we can then start building the application.

We will build an API similar to that used by a blog that publishes posts from multiple users.

Defining the GraphQL Schema

Let’s begin putting together the application by first defining our GraphQL schema.

At the root of your project, create a folder named src; this is where all of our application logic will be located.

Within the src folder, create a file named schema.js and place the following code in it:

In the file above, we define two custom types: User and Post. These represent the blog user and their posts, respectively.

We also defined our Query type to have two queries. The users query returns an array of users and the user query returns a single user whose id matches the argument.

Finally, we export the schema on the last line.

Mocking data

Since this is not a production application, we will not be using a real database for our data. Instead, we will be creating a mock of the MongoDB database using the mongodb-memory-server. This will allow us to create and use an in-memory instance of MongoDB. In production, you would want to set up an actual MongoDB instance or use a MongoDB service like Mlab.

Let’s install the required packages by running the following command:

Once the packages are done installing, the next step is to create a file to hold our mock data.

Within the src folder, create a file with the name data.js and place the following code in it.

The file above exports an object, which contains an array of user data. Each user object also contains an array of that user’s posts. This is the data we will be bootstrapping our in-memory MongoDB instance with.

The next step in mocking our data is setting up our database instance using the mongodb-memory-server package. Create a file named database.js also in the src folder and place the following code in it.

In the file above, we export a startDatabase function that sets up our in-memory MongoDB database.

It checks if an instance of the database already exists. If it doesn’t, it bootstraps it with a users collection and seeds the collection with the Users array we defined earlier in our data.js file.

Awesome!

Defining our Resolvers

The next task at hand is to define the resolvers to our queries. Remember we defined the two queries users and user to return an array of users and a single user, respectively.

Within the src folder, create a file named resolvers.js and place in the following code.

In the file above, we export an object containing two resolvers — one for each of our queries. We also use the context object, which we will set up later on.

Preparing the Application for Tests

You might be asking at this point, “Why are we setting up tests when we haven’t even wired up our GraphQL server to start up and receive requests?”

The answer to that is as follows.

Most developers set up the server application and listen for connections in the same file; this file is the entry point of the application like below.

But, in order to test our GraphQL endpoints, the server setup logic and the part where we listen on a port needs to be in separate files. One file holds our server logic and exports the server app, and another file boots up our application.

This way, we can import our server into our test files and run the appropriate tests on it.

Before we create these files, go ahead and install the graphql-playground-middleware-express module, which helps us set up a classy playground for testing our GraphQL endpoints:

Now, let’s create these files for our GraphQL server. Within the src folder, create a file named server.js and place the following code in it.

In the file above, we set up our Node.js application, our GraphQL context to contain an instance of our in-memory database, our server GraphQL endpoint, and GraphQL playground endpoint. We then export our app as expected.

The next step is to create the file to boot up the server. Create a file named index.js and place the following code in it.

In the file above, we set up the startup script by importing our server and listening on a port.

Our application is now ready to function. Let’s add a start script to package.json to run the application.

Great!

Now let’s take the app for a spin by running the following command:

After running this command, you will see the success message logged to your console. To test that the server is running, navigate to http://localhost:4000/playground to open up the playground. In the query window of the playground, run the following query:

This should give you the output shown below:

Great!

Now we have visual and functional confirmation that our GraphQL server is working as expected.

We are not here because we want to test our endpoints manually through the playground, though. No, no, no. We are here for automated testing and that’s what we are going to enable in the next section. Before then, make sure to push this project to a GitHub repo. Set up a .gitignore file to ignore the node_modules folder before pushing your code to your repo.

Setting up the Test Script

We want to add tests to our application and include a test script that runs all of our tests whenever we push code to our repo. Pretty neat, right? Let’s go ahead and set that up.

First, we need a testing framework. The framework we will be using in this post is Jest.

Why Jest? Because it’s easy to set up (almost requires no setup at all) and has a fluent, comprehensible API.

We also need a library for testing HTTP endpoints, and for this we will be using the Supertest NPM library. Supertest is an easy-to-use HTTP testing library that works seamlessly with any testing framework.

We will be combining the Jest testing framework with the supertest HTTP testing library to test our GraphQL server.

Let’s install these two libraries as development dependencies to get started:

Great!

Once these libraries are done installing we can begin writing our tests.

Jest tests can be grouped in a special folder named __tests__ (double underscores on each side), so create this folder at the root of your project.

Create a sample test in this folder by creating a file named sample.js and add the following test to it.

Next, install Jest globally by running this command:

Now run the jest command at the root of your project. This should run the test and output the success messages onto the console.

Great!

Now we have confirmed that Jest is running fine.

We will be creating another test suite to test our queries. This will test the users query and check that it returns the appropriate status code, data type, and number of users.

Create a file named queries.js inside the __tests__ folder and place in the following code:

In the file above, we imported our server and used it to set up a request object with supertest. This allows supertest to internally bind the server to a port.

We then query our /graphql endpoint with some query data by sending a POST request to it.
Once we get a response, we use Jest to check that the appropriate status code, data type of the data (an array of users is expected), and the exact number of users we seeded in our database is returned.

Awesome!

Now, let’s set up the test script to run our tests. Just below the start script in package.json, create another script named test to run the jest command as shown below:

If you already have a test script, defined by running npm install –save-dev jest supertest, edit it to what we have above.

Now you can run the following command to run the test we just added:

You should see a screen similar to the one below in your console.

Great!

Now let’s automate this test process.

Automating our Tests with CircleCI

To begin our test automation, we need to build a continuous integration pipeline that CircleCI will run.

The pipeline will do the following:

• Check out our repository
• Install the required dependencies
• Run all our tests

To do this, we need to write our pipeline script for CircleCI to pick up, build, and run our pipeline.

Create a folder named .circleci at the root of your project and create a file named config.yml inside it.

Now paste the following code inside.

The script above imports a Docker image suitable for Node.js applications, checks out our code from the repo, installs the required packages, and runs our test script.

Now commit your code and push it to your repo.

Next, head over to your CircleCI dashboard and add the project in the Add Project section.

Next to your project (in this case testing-graphql), click Set Up Project.

This should bring you to a page similar to the one below.

Now click Start Building.

This will bring up a dialog asking if you want to create a new branch of the project and have it contain the suggested pipeline configuration displayed, or if you want to add it manually.

Click Add Manually so that CircleCI picks up the config.yml file you just pushed to your repository.

Another dialog then pops up asking you if you have added a configuration file, or you would like to download one. Click Start Building to confirm that you’re good to go. This will trigger CircleCI to run your pipeline with the configuration file in your project.

If all of your tests run successfully, you will see a screen similar to the one below.

Now click into the build process to see how the pipeline ran and confirm that the tests passed successfully. You will see a screen similar to the one below.

Awesome!

Add another test to your queries.js file with the code below. This test checks for an events query that does not exist on our server to see if the appropriate status code is returned

Save the file, commit your code, and push to the repo once again to see your pipeline run.

Conclusion

GraphQL makes life easy for both front-end and back-end developers, as it provides a very flexible API to query. Ensuring that these APIs are well-tested keeps the quality intact and brings peace of mind to the developers — knowing that any code being pushed is verified before deployment.

Happy Coding!

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Udemy, Docker.

Feature image via Pixabay.