The Simple Way To Unlock Third-Party API Testing

Delivering a successful user experience is a continuous challenge. You must meet the user’s expectations while ensuring non-functional requirements such as performance, privacy, and security.

A website has on average 40 calls to external APIs for analytics, consent, and other partners services. These APIs are not optional; they are part of the user experience and therefore important to test.

Traditional test automation tooling is narrowed. You can perform functional tests on a web or mobile interface, but not API ones. On the contrary, you can test APIs but not the user interface.

In this article, we share a simple way to implement test automation for your 3rd-party APIs within a web application. We use Cerberus Testing in three steps:

Identify your 3rd-party APIs expectations
Configure your test to collect the network data
Add your expectations with filters and controls

First things first, let’s start by exploring and defining your expectations.

Identify your 3rd-party APIs expectations

The first step is to know which external calls are most important to test. Ideally, you have the knowledge of the application. You can also ask the product and engineering teams about specific integrations, involving them in the initiative.

Additionally, you can identify the various 3rd-party calls just using your web browser. In Firefox, you can access various traceability elements with a right-click on “Inspect”. The data you are searching for is on the “Network” tab.

Figure 1: You can access the 3rd-party API calls in the browser.

While browsing your website, the various 3rd-party API calls will appear on that list. The important elements to note are the domain and the request. They will be necessary to define your assertions.

The next step is to retrieve these data inside your test.

Configure your test to collect the network data

Accessing the browser and network traffic data is not trivial. If you have your own test automation framework, a great deal of coding and integration is required to retrieve, parse and make the data actionable.

You can natively access these data in a formatted way using Cerberus Testing. You just have to define the two required actions in low-code after each page you navigate. The two specific actions are the following:

“waitNetworkTrafficIdle” will start data collection and the right moment
“setNetworkTrafficContent” will actually collect the data

Figure 2: You need two specific actions after each page to collect the data.

From that point, your test case will collect the network data at each execution. You can test your setup by running the test case. One point to secure is that your Selenium robot is running with a proxy to actually access the external data. If you use a Cloud plan, this is natively available, else you need the specific robot available on GitHub here.

Figure 3: The data are natively formatted in JSON to ease your testing in Cerberus.

You access the above data in a formatted way after the execution. The data are in JSON to ease your reading and control and are already split with global and per domain metrics. You can concentrate on the verifications without the need to code technical parsing.

You are now ready to add the desired controls in your various test cases.

Add your expectations with filters and controls

You can replicate the shared structure to capture network data in your test cases. Using the filters and JSON verification will ease your journey: you just have to specify the various expectations per provider with an action and a control.

The action remains with the “setNetworkTrafficContent” where you can use a filter or not. In our case, we filter on “google-analytics” to have a simpler control afterward, already filtering the number of calls performed.

Figure 4: Define the necessary filters and controls per 3rd-party in low-code.

The control on “$.stat.total.requests.nb” access to the value in the formatted JSON prepared by Cerberus Testing. “Stat” stands for “statistics” and “nb” for “number”. You can use the same structure and control keyword to verify any element of the JSON.

Figure 5: Access the results easily in the native test reporting.

You can even add these controls to your library, to be reusable across test cases and replicable within your test. You can also add dynamic parameters per country or from a previous test case using a property.

This is only the start of improving your product quality.

Expand your initiative with continuous improvement

We covered the 3 main steps necessary to add 3rd-party APIs called verifications within your web application. Cerberus Testing enables you to accelerate your test automation journey by natively providing the required features.

We shared the simple case of ensuring a call was made to a 3rd-party. You can go further with the framework and data available by checking the results of the API call, and even verify the response time remains under a particular SLA.

User interfaces are the results of a valuable composition of technologies. As engineers, it is our responsibility to ensure their integration is supporting a successful user experience constantly improving.
Interested in improving your user experience? Get Cerberus Testing for free here.

The Simple Way To Unlock Third-Party API Testing