Running Tests Made Easy with REST- assured and GitHub Actions

Rohit Kumar
ANAROCK
Published in
5 min readApr 2, 2021
source REST-assured

This is my first blog and I am sharing my experience on how I transitioned from manual to automation functional testing at ANAROCK Technology. Other aspects covered in the blog include how I used to do API testing manually, what challenges I faced, and how I started backend testing automation.

API testing is intensive and plays a vital role in ensuring that your APIs work as seamlessly as possible and continue to deliver value to your business and customers over time.

Functional testing makes sure that the API is working as expected with a defined set of parameters and throws errors when passing undefined/unexpected parameters.

Functional testing is the process through which QAs determine if a piece of software is acting in accordance with pre-determined requirements. It uses black-box testing techniques, in which the tester has no knowledge of the internal system logic. Functional testing is only concerned with validating if a system works as intended.

Source: Browserstack

To understand better, let’s consider a few log-in process scenarios:

  1. If a user submits a valid username and password, API returns HTTP status code 200 OK, with basic user information.
  2. If a user submits wrong credentials either username or password, API returns HTTP status code 401 Unauthorized, with an error message.
  3. If a user submits a username that doesn’t exist, API returns HTTP status code 404 Not Fund .

QA performs such scenarios to check if a log-in API functionality is working as expected or not.

The Problem

Post every staging deployment in any service, we used to conduct testing across all services end-to-end manually. This was very time-consuming and was not feasible to ship any changes to production under the timeline.

Doing API migration testing manually was also a difficult task. I often made mistakes while copying some ID from a POST method response, and passing the same in some GET method request body. I wasn’t able to cover all business logic testing, because more time was spent in putting correct values to hit APIs with all possible request parameter combinations and hitting APIs in a specific sequence order.

The exploration

To begin with, we started using Postman to tackle problems in API testing, hitting APIs manually and check for the responses. But this also involved a lot of manual efforts.

At this stage, we decided to set up an API testing framework, which can be integrated with any CI/CD.

I started writing automated tests using Minitest, a testing library for Ruby. It’s the default testing framework for Rails.

Soon we realized that we can’t continue writing tests using Minitests for all services as they have different frameworks(Elixir, Python). Writing and maintaining tests in different frameworks would be difficult. So I decided to select a framework, which will be independent of our backend tech stacks, whether it is RoR, Elixir, Python, GoLang, etc.

Given below is a comparison chart of all the available options:

Comparison chart of API Testing Tools | source

The Solution

I decided to go ahead with Rest-assured because I was familiar with Java programming language. Here are the other reasons for choosing REST-assured:

  1. Open-source Java library.
  2. Supports BDD paradigm:
    Given : it defines the pre-condition. Ex : (ContentType.Json), (auth_token),(cookies).
    When: it defines the action to be performed with which API.
    Then : it defines the outcome of when to step and validates the response.
    Ex — statusCode (200).
  3. Not required to be an HTTP expert to start working with this.
  4. It supports all the HTTP methods like GET, POST, PUT, PATCH, DELETE, etc.
  5. Easy integration with TestNG, customize reports.
  6. Based on Java so one can get help from the huge Java community.
  7. Any person with basic java knowledge can go through documentation and start writing test cases.

How to get started with Rest Assured

Setting up

Add REST-assured and TestNG as dependencies in your maven project pom.xml :

...
<dependency>
<groupId>io.rest-assured</groupId>
<artifactId>rest-assured</artifactId>
<version>4.3.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>7.4.0</version>
<scope>test</scope>
</dependency>
...

You can check the latest versions for Rest-assured and TestNG here.

Writing Tests

Create a class under src/test/java and then create a test method in it :

A sample test method

As an example, I have created below a sample test using the public API of zippopotam which gives a list of places associated with country and postal code.

package restassured;

import io.restassured.http.ContentType;
import org.testng.annotations.Test;

import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;

public class FirstTest {

@Test
public void getCall(){

given()
.when()
.get("http://api.zippopotam.us/IN/110001").
then()
.assertThat()
.contentType(ContentType.JSON)
.body("places[0].'place name'", equalTo("Janpath")).and()
.body("places[0].'state'", equalTo("New Delhi"));
}
}

Here, I’m validating the response status code, content type, and body.

If test passes with both assertions, in IDE console it looks like:

The total number of tests passed showing

If the test fails, in the IDE console it looks like:

assertion failure
content type failure

Deploying on GitHub Actions

GitHub action workflow diagram

In GitHub repo, devs can push, create a PR, release, or an issue that can be used as triggers to start a workflow. Workflow is a collection of jobs which in turn consists of a series of steps that will be executed sequentially.

Workflow file exists in a repo folder .github/workflows . This folder should contain all the workflow you want to write. For more information on how to write workflows refer to GitHub Actions documentation.

A workflow snippet which we use

Now, whenever any changes are pushed to the master branch, workflow gets triggered and starts executing all the written tests.

This is just a blog to get you started. In my next blog, I will share some examples of commonly used HTTP methods, Spec builders, TestNG data provider, and Test report generation.
Stay tuned and watch this space for more!

--

--