This Is How To Test GraphQL APIs Without Coding

GraphQL is emerging as an elegant solution for flexible, decoupled and dynamic data access. But how to test it properly?

In this article, we introduce GraphQL in the API ecosystem to understand its history and key concepts. 

We then implement a concrete GraphQL API test case using the Cerberus Testing open-source framework.

Why GraphQL is emerging

We need to understand the key elements of the APIs history.

APIs have emerged mainly during the SOA era, supported by SOAP/XML-based protocol. It helped organizations building reusable services aiming for a simpler integration than their predecessors. The main issues with SOAP lie in its verbosity and standardization. The vendor competition led to a variety of implementations, lacking the initial ease of integration pursued.

This is where REST appears as a lightweight and standard alternative, that became truly popular in the IT industry. The ecosystem of documentation, tooling like swagger, API portal enable truly API-led initiatives and enterprise API management. In parallel, the use of mobile devices has been replacing traditional desktops.

The rise of mobile applications created a drive to deliver faster and better these apps. A key pain point of mobile developers was in its integration with backend REST APIs. The problems faced are linked to the static and technically coupling between the front and the back-end. This is where Facebook engineers developed a more elegant solution, called GraphQL.

What is GraphQL

GraphQL aims to simplify the consumer integration with back-ends APIs. Its key concept is to access dynamically to data models that are described and that evolve with less coupling between the consumer and the data producers.

Technically, GraphQL shares common characteristics with REST APIs :

• It relies on the HTTP protocol 
• Supports for both GET and POST mechanisms
• The format application/json

The main differences are on the data retrieval mechanisms, which was in fact the problem to be solved. Its main elements are the query, operationName and variables. They enable you to compose flexible queries to the back-ends, simplifying your development and data usage. The response contains data and errors elements.

Let’s now move to the testing part.

Good practices of testing GraphQL APIs

Testing GraphQL APIs will be more efficient in understanding the good practices.

Firstly, avoid the use of GET methods. GraphQL provides dynamic querying mechanisms over three variables in its foundations, so POST is the de-facto standard for this use case. Trying to use a GET method will be overly complex to set up and maintain. You could end up with a query of the following style.

http://myapi/graphql?query%20aTest(%24arg1%3A%20String!)%20%7B%20test(who%3A%20%24arg1)%20%7D

The request parameters in JSON and Gzip compression are also important for both the development and testing. JSON is in fact optional in the protocol, even if the market practice is to leverage the power of JSON that has been largely proven with REST. The compression can be activated using the following parameters.

Accept-Encoding: gzip

Finally, apply the standard API best practices such as a versioning strategy supporting non-breaking changes, null cases management, return only asked data and pagination for the sake of performance. Those themes are standard and a framework to define in your organization, GraphQL providing the protocol.

Talking about a framework, we can also simplify our life relying on a test framework.

Test GraphQL APIs using a Framework

We will use the Cerberus Testing framework and this public GraphQL API that you can then expand on various use-cases.

In pre-requisites, you need to have a Cerberus Testing instance setup, on your own or using one of the Plans available. 

The 3 key elements to use in Cerberus Testing are :

1. Application: Define your application under test environments 
2. Service: Configure reusable GraphQL API call including headers and parameters
3. Test Case: Your actual steps, actions and controls to perform an automated verification

The application definition consists of selecting the service application type “SRV” and defining your couple of countries and environments. Those various values can be completely customized in the parameters.

We can now move to the service definition, selecting the REST service type and the POST method.

The last configuration step is to define our request and eventual request header in the other tabs. Here’s one way to fill the JSON query in the “Request” tab.

From now on, you can leverage the test case framework with step, action and control to compose your test case. The callService action is one to use for each GraphQL call you want to perform. You can then use the various controls available to perform static or dynamic verifications.

Your test can be run in the various application environments you have defined using the various execution mechanisms available. 

Expanding your GraphQL Testing

The structure we share can be applied and scaled to a variety of use-cases.

You can include those tests in a campaign to be scheduled or triggered within a CI/CD pipeline. Complementary, the Data Library can let you retrieve dynamic datasets for both actions and controls let you handle more complex scenarios and coverage matrix. 

Focusing on the initial use-case of GraphQL, you can perform mobile app tests on real or emulated devices that are performing specific GraphQL calls within your tests. This particular case of full-stack white-box testing can be useful for functional and integration test scenarios.

This is where the power of using a framework comes, you can stop coding and start testing. We hope that you will leverage Cerberus Testing in your test automation journey. Feel free to comment, engage and try it out. Various videos are also available.

Star the project on GitHub if you liked this article 🙂