API Testing

Overview

With Reflect’s API testing feature, you can generate API requests and validate API responses as part of a larger end-to-end regression test, all without writing code. Supported actions include inserting dynamic values into an API request, extracting values out of an API response, and asserting on various aspects of the API call, including its HTTP response code.

Common Use-Cases

While there are many potential cases for API testing, what makes Reflect unique is that you can issue API calls alongside UI actions, and share state across these test steps. Below are a few common use cases where combining API and UI actions can come in handy:

Calling APIs to generate test data

In many cases, end-to-end tests depend on pre-existing data within the system-under-test. For example, in order to automate testing of a “Delete” action within your web app, you’ll first need to ensure that an entity already exists which can be deleted. These types of destructive test cases are often hard to automate, since the state of the application changes after every test run, and must somehow be reset.

One use of Reflect’s API Testing feature is to issue API calls to set up test data as part of a larger end-to-end test. When testing a destructive action like in the example above, we could issue an API call at the beginning of the test which creates a new entity, and extracts some unique identifier for that entity from the API response. We can then record the steps to search for that entity in the UI using the identifier that was extracted from the API response, and finally delete the entity using the UI.

Verifying results through API calls

For modern web apps, system state is often stored across a variety of disparate systems. If you’re using a microservice architecture, state will be stored across a set of services and exposed via APIs. In addition, third-party integrations such as Stripe for billing or Auth0 for user identity information often act as their own systems of record.

Using Reflect’s API testing feature, you can validate that the proper updates have been made to these first-party and third-party systems after completing an end-to-end workflow by issuing API calls and validating the API response.

For example, when testing an end-to-end test that adds a payment method, you can end the test by making API calls to Stripe’s API to validate that a relevant Customer and PaymentMethod object has been created.

Defining an API request

To add an API call to your test, start a Recording session and click the Add an API Call button:

After clicking this button, a new section will be displayed that provides options for declaring an API request and validating its response:

Using dynamic values

Dynamic values can be inserted anywhere within the request URL and request body, and can be extracted from the response body. In order to reference a dynamic value, the value must first be assigned to a Variable in an earlier test step or in an Execution Override passed at the outset of the test.

There are two ways to assign a dynamic value:

1. To replace text: Highlight the text you want to replace and select the Replace with Variable option. In the context menu, click the Variable containing the dynamic value you want to insert.
2. To insert text: Click the text field and move the text cursor to the location where the dynamic value should be inserted. In the toolbar that appears, click the Insert Variable option and click the Variable containing the dynamic value you want to insert.

Testing an API request

After populating the necessary fields for the API request, you can generate an API response by clicking the Send Test Request button on the top right of the screen. This will generate an API request using the values you’ve specified and will populate the response in the Validate Response section.

After saving and executing the test, Reflect will issue that same API call and validate its response against the criteria you have specified. If one or more validations fail, or if the API response times out, the test step will be marked as failed and information about the failure (including the API response that was received, if any) will be included in the test run details.

Verifying an API response

Once an API response is generated, either via the Send Test Request button or when viewing a completed test run, you can extract values from the response by clicking on the relevant fields within the Validate Response section.

When you select a property in the response, you’ll be prompted to choose from a number of options, including assigning the property value to a variable, or making an assertion on the property value. When you’ve made your selection, the property will be highlighted and an editable “selector” will be generated. For JSON responses, the selector represents an associative array or dictionary that identifies the property within the context of the JSON document. For XML responses, the selector will be provided in XPath 1.0 format.

JSON Responses

Consider the example API response below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "totalCount": 2,
  "users": [
    {
      "name": "John Doe",
      "role": "Guest",
      "isActive": false
    },
    {
      "name": "Jane Doe",
      "role": "Admin",
      "isActive": true
    }
  ]
}

Here is how Reflect’s JSON selectors can reference various properties within this API response:

• Access property by name: ["totalCount"] - Returns 2
• Access array element by index: ["users"][0]["name"] - Returns "John Doe"
• Access boolean values: ["users"][1]["isActive"] - Returns true

XML Responses

In addition to supporting responses in JSON format, Reflect also supports validating API calls in XML format. Similar to JSON responses, values in an XML response can be extracted simply by clicking on the relevant attribute or element value. After selecting the extraction or assertion rule, the attribute or element value will be highlighted and an editable XPath 1.0 selector will be generated.