Automation Testing Part 2: API Testing Using Rest-Assured

In my first post in the automation series, I explained a simple three-step process to start any automation testing. In this post, we will dig into REST API testing, its importance, how to create tests using Rest-Assured and how to integrate them with your ongoing development efforts. In the next post, I will discuss UI testing best practices and principles for mobile applications using Appium.

 

Overview

Making sure your REST API is in tip-top shape is very important, as it is almost always responsible for your applications running smoothly. This, however, comes with a big challenge; how can we ensure that these API services are running as expected? How can we make sure that these services are not degraded with time as more and more code is added? Well, one way is using a tool dedicated to REST API testing and integrating with a proper CI (Continuous Integration) to ensure that they work as anticipated over time. Let’s start by talking about Rest-Assured and how to put it to use.

 

Rest-Assured

Rest-Assured is a Java based DSL (Domain Specific Language) which is most commonly used to test out REST based services. Rest-Assured presents a great advantage because it supports multiple HTTP requests and can validate and/or verify the responses of these requests. These multiple requests include GET, POST, PUT, DELETE, PATCH, OPTIONS and HEAD methods. Given that it supports these various requests, it also allows for them to be constructed with multiple parameters, headers, and their respective body, as well as validating response’s status code, headers, cookies and response time. For the next set of examples, we will be using JSON based requests and responses (application/json). This is very similar for XML requests as well. So now, let’s dig deeper with some code.

Here lies the first step in creating most of your HTTP requests (except for GET calls), your request’s body. Referred to from now on as the service request class, it stores the various JSON values or properties used to create your request body.

 

Next, comes your response. The responses that originate from your various HTTP requests are more than likely to return a body. In this case, GET requests almost always do. For that reason, we can also create a response class to store those values.

 

Now that we have taken care of the request and response bodies, and have created the properties that we expect to receive from them, let’s get our test going. For these examples, we will be using Cucumber. Cucumber uses Gherkin language and BDD testing to run the different scenarios under test.

 

Scenario 1: POST Request

 

Scenario 2: GET Request

Up next, it’s time to build out our services. Recall that these requests can be constructed with multiple parameters, headers, and other options, as well as various HTTP methods and can hold a response body to be used later to create our assertions. This is essential, as this will mark the difference between a passing or failing API call.

 

Scenario 1: POST Request

 

Scenario 2: GET Request

 

Then we call on the service object’s methods – this was created in the earlier step inside our step definition class to execute our API calls.

 

Scenario 1: POST Request

 

Scenario 2: GET Request

 

Finally, with our responses stored and ready to go, we can begin making assertions on the result. These assertions can vary tremendously and are specific to every scenario. However, popular assertions can be validating data inside the response body, validating the presence of a header, or validating a specific status code.

 

Scenario 1: POST Request

 

Scenario 2: GET Request

 

All we need now is to run these tests in an automated way, either in sequence or in parallel. Luckily, given that Rest-Assured is a Java based DSL, it can easily integrate with Gradle, Maven, or other any other build tools to deliver this. Let’s take Gradle for example, we can easily build out a new task which will integrate with Cucumber and the scenarios inside our feature files and execute our tests as needed.

 

Another option that can integrate fairly easily with BDD tests in Java is Cucumber-reporting. After executing the respective task, an HTML report will become available and troubleshooting succeeded and failed executions will be possible. All that’s left is to create a Jenkins job executing our task from our chosen build tool and we have successfully created an automated code base used to validate the correct execution of our REST API.

 

Conclusions

Rest-Assured is not only a great tool to test out REST API calls in a fairly easy manner, it also delivers the opportunity for the Quality Assurance team to develop side by side with developers in any Agile methodology to ensure the highest quality possible of the core architecture that drives their applications. In the next post, I will discuss UI testing best practices and principles for mobile applications using Appium. Can’t wait!

Subscribe to our Blog

Rodolfo Conejo
Rodolfo Conejo
Rodolfo has been a .NET/backend developer for around five years now. He started working on automation testing technologies in 2014 with a focus on UI/UX. Rodolfo enjoys watching movies and solving jigsaw puzzles in his free time.

Deliver off-the-chart results.

WordPress Video Lightbox Plugin