REST API Test Automation in ACCELQ

This guide walks you through the process of creating, configuring, and verifying a REST API call directly from the logic editor within your ACCELQ project.

Initiating an API Call

To get started, you'll need to be inside an Action in your ACCELQ project. The process begins from the logic editor.

1. In the statement line, click the + API button.
2. From the dropdown menu, select Insert REST call. This will open the REST service configuration wizard.

Configuring REST Service Information

Once you've started a new REST call, you'll provide the details for the API endpoint you want to test. This screen captures all the essential information for making the API request.

• Reference Name: Give your API call a unique and descriptive name. This name is used to refer to this step in your test logic.
• Endpoint URL: Enter the full URL of the API endpoint. You can parameterize this by clicking the parameter icon (☰) to define the value as a Literal, Action Parameter, or Global Property.
• Method Type: Choose the correct HTTP method (e.g., POST, GET, PUT, DELETE, PATCH) from the dropdown menu.
• Headers: If your API needs specific HTTP headers, you can add them here:
  1. Click + Add New.
  2. Enter the header name (e.g., Content-Type, Authorization).
  3. Enter the header value. This can also be defined as a Literal, Action Parameter, or Global Property.

After filling in all the required information, click NEXT.

Defining the REST Request Payload

For methods like POST or PUT that send data to the server, you'll need to define the request payload.

• Payload Type: Select the content type of your payload from the dropdown. Common options include application/json, application/xml, multipart/form-data, and text/plain.
• Entering Payload Data: ACCELQ gives you two convenient ways to input your payload data. You can switch between them by clicking the toggle icon (T).
  • Outline View: This presents the payload structure as an interactive form. It's the most straightforward way to build a structured payload like JSON or XML.
  • Text View: This provides a text editor where you can directly type or paste the raw payload content. This is handy if you already have the payload in a text format.

Once your payload is defined, click SEND REQUEST to execute the API call.

Reviewing the API Response

After the request is sent, ACCELQ displays the Response Information screen with a detailed breakdown of what the server sent back.

Here, you can review the following:

• Status: The HTTP status code of the response (e.g., 200 OK, 404 Not Found).
• Headers: A list of all headers returned by the server.
• Response: The main body of the response. For structured data like JSON, ACCELQ presents it in a collapsible, easy-to-read format.

You can analyze this information to confirm the API is behaving as expected and add verifications directly from this screen.

When you're finished reviewing, click SAVE to add this API call as a step in your action logic.

Saved Action Statements

When you click SAVE, ACCELQ creates two distinct, human-readable statements in the action logic. This approach separates the execution of the API call from its verification, leading to cleaner and more maintainable test logic.

1. Invoke ReSTful POST service Statement

   This statement is what executes the API call. It neatly summarizes the configuration you provided:

   • Method: The HTTP method.
   • End-point: The URL you specified.
   • Request headers: Any headers you added.
   • Body: The payload you defined.
   • Reference name: The unique name you gave the request (e.g., 'test'). This name is crucial as it links the request to its verification step.

2. Verify the Response for ReST call Statement

   This statement handles the validation of the API's response. It uses the Reference name from the first statement to know which response it needs to check. The Expected Response parameter is where you define your verification criteria, such as:

   • Asserting the response status code (e.g., 200).
   • Verifying the value of a specific field in the response body.
   • Checking for the presence of certain headers in the response.

By separating these two concerns, you can easily modify the request payload or the verification criteria independently, making your API tests robust and easy to manage.