Introduction to Integration Testing

A core feature of API Fortress Is the ability to perform integration testing.
See our video example here.

(You can follow along with the example in the demonstration by viewing it in the API Fortress platform here: Quick Integration Demo)

Integration testing is core to creating a strong API testing strategy. Microservices are built to work together, and an integration test allows you to create end-to-end tests that resemble common user flows. Only testing individual endpoints is a good start, but will miss a huge amount of problems that occur when all the services need to work together.
Let’s consider an example. Company A has an authentication server. This server, when given the proper user credentials, returns an authentication token. This token is required for all other calls throughout the platform’s API environment. Without this first API call, none of our other API calls can work. The proper tool for this job is an integration test.

Getting Our Token

 First, we need to make our POST call to the authorization server.

Screen Shot 2018-04-12 at 12.20.27 PM

 In this case, the request body is the username and password. In return for proper credentials, the authentication server is going to return a user token.
Next, we need to use this token to make further calls to the application.

Setting a Variable

First, we need to assign the token to a variable. Variables are used to store data temporarily for test. You can use the Vault for more permanent variables (more information here). We do this so we don’t have to manually invoke or set it every time it is needed.
We add a “Set” component, and enter the information as seen in the image below.
Screen Shot 2018-04-12 at 12.31.27 PM
We’re calling the variable “access_token” and assigning the value to ${payload.Token}.
The response body from the original post call was saved to a variable called “payload.” The key to access the token is named “Token,” so we find it by calling “payload.Token”. We wrap this all in ${} so that API Fortress knows to interpret what’s between the brackets instead of using it literally.

Making Follow-up Calls

We’re nearly there. We made our authentication POST call, we then saved the token to a dynamic variable named “access_token.” Now it is time for the third, and for this example, final step.

This API has a cart function that requires a user token in order to add items to a cart, or to view the items currently in the cart. We are going to use the access token we were granted by the authentication server to add some items to a cart.

Screen Shot 2018-04-12 at 12.38.22 PM

We will use a PUT request to the cart endpoint to update the cart. We’re setting the “usertoken” header to ${access_token} (same notation as before). The request body is a JSON object that the server will recognize as items and quantities. That part isn’t important for the purposes of this demonstration.

Why?

As we said in the start, it is imperative to not just exercise endpoints, but validate that an entire series of microservices are working. It’s best to do that by writing tests that emulate common and uncommon user flows. A critical part of that work involves creating reusable variables to allow the test to work at any time, with any data.

By making a request for a fresh token at the beginning of the sequence, and then assigning it to a variable, we know that any time we run this test we’re doing so with a valid access token and that our access token is automatically being passed to all follow-up calls.

We can keep using the same access token over and over, as seen below.

Screen Shot 2018-04-12 at 12.39.20 PM

That is simple integration test. Please feel free to reach out to us should you have any questions, or take a look at the Examples project which contains other examples.