Basic API Test Automation

End-to-end API testing flows can involve multiple input sources, such as HTML, Databases, Telnet/SSH, Mobile, Shell, Data files, other RESTful APIs and more. TestProject‘s test automation platform allows not only testing your APIs manually, but also to complete end-to-end API based test automation flows, schedule and run them periodically, get execution reports and all of that without any third party tools and without a single line of code 🚀

This hands-on tutorial consists of step-by-step examples and real automated test flows, shared here for you to use and practice while automating your APIs. In this chapter (Chapter #1), we will review basic API test automation examples. You can access the tests mentioned in the examples below by using the following shared test link: API HTML and Dynamic API Endpoint Test.

Table of Contents – Automating End to End API Testing Flows

1. Overview – Automating End to End API Testing Flows
2. You’re here → Chapter 1 – Basic API Test Automation
   • Basic HTTP Get Example
   • GET with Dynamic Endpoint URL Test Example
   • HTML and RESTful API Test Example
3. Chapter 2 – API Test Automation Flows Combined with Mobile Functional Test
4. Chapter 3 – API Test Automation Flows Combined with Databases Flows
5. Chapter 4 – API Test Automation with Combination of Shell Commands and Local Files
6. Chapter 5 – Advanced API Test Automation and Validation Flows
7. Chapter 6 – Scheduling API Automation Flows and CI/CD Execution

---

Basic HTTP Get Example

The TestProject Addon you’ll need to use in this tutorial is called RESTful API Client. It allows you to send: GET, POST, PUT, DELETE and PATCH requests. You can find it in the Addons section on the TestProject platform.

After installing the addon, you can add these API calls to your tests by creating new actions and searching for them while recording, and selecting them:

Let’s create an API request to the NASA public API.

Create an HTTP GET Request:

In our initial step, we will retrieve all of the available asteroids by using the command and extracting the first asteroid ID (https://api.nasa.gov/neo/rest/v1/neo/browse?api_key=DEMO_KEY).

Let’s add the relevant paraments needed to get a reply:

URL
https://api.nasa.gov/neo/rest/v1/neo/browse

Query
api_key=DEMO_KEY (you can add multiple parameters here separated by ‘&’).

ExpectedStatus
We will enter the code “200”. According to NASA’s documentation, the expected server status in case the request is valid will be 200.

JsonPath
$.near_earth_objects[0].neo_reference_id (based on Jayway JsonPath syntax, we are looking for a first neo_refernce_id, that will be passed as part of the endpoint for our next step).

We will also add a parameter (server_response) for the Response field, in order to store the retrieved first neo_reference_id.
This is how the step is supposed to look like in our step editor:

Let’s click on “Create”. Now, a step will be created and executed successfully. This successful execution will retrieve the response message (displayed below). Note that the specific value that we searched for, by using JayWay syntax, will be stored in the server_response parameter we created (as seen in the image below, it equals 2021277):

GET with Dynamic Endpoint URL Test Example

Now, let’s create a dynamic endpoint URL according to the asteroid ID that was retrieved above, and extract from the server response the nasa_jpl_url which represents the URL to a web page that provides full information about the asteroid.

According to NASA’s API documentation, the asteroid ID (aka neo_reference_id) that was retrieved above is part of the endpoint that provides us detailed asteroid information as shown in the following example:  https://api.nasa.gov/neo/rest/v1/neo/2021277?api_key=DEMO_KEY.

In this step, we will create a GET request by using the neo_reference_id value that was stored in the server_response parameter, to assemble the endpoint URL and retrieve a new value called nasa_jpl_url from the response message.

Let’s add a new step (action type step) within our recorded test. Then, search for the action GET. Then, you will see the HTTP GET Request action. Select the action and add the relevant parameters below:

URL
https://api.nasa.gov/neo/rest/v1/neo/server_response

Query
api_key=DEMO_KEY (you can add multiple parameters here separated by ‘&’).

ExpectedStatus
We will enter the code “200”. According to NASA’s documentation, the expected server status in case the request is valid will be 200.

JsonPath 
$.nasa_jpl_url (based on Jayway JsonPath syntax, we are looking for a nasa_jpl_url value).

We will also add a parameter (Asteroid_URL) for the Response field, in order to store the retrieved value (nasa_jpl_url).
This is how the step is supposed to look like in our step editor:

Now, let’s run our test steps and view the result.

As seen in the response schema displayed below, we received the specific asteroid id details. Both GET requests (from step 2 and from step 3) are related: the second call (in this step – step 3) is going to a specific endpoint based on the first REST API call (from step 2).

HTML and RESTful API Test Example

And now, we can navigate to the URL retrieved from the previous API call.

And perform a validation using the parameter extracted from the first API call.

🌟 TAKE ME TO CHAPTER #2 🌟