Technical requirements- Digital Transformation with IBM API Connect-1

The examples presented in this chapter will require that you install API Connect, along with the test and monitor tool. You should also have at least one API developed and published that you can test within your test cases.

Configuring unit tests

As you develop and change your APIs, you should be unit testing them incrementally with specific unit test cases for the change you have just made or testing the API in general. The API Connect test and monitor tool allows you to quickly generate these unit tests by simply sending a request to the API URL and getting a response. This tool will provide some assertions that you can use as-is, alter, delete, or add to. Let’s take a look at how to configure a simple unit test case for an API that you are working on.

Before you start to create your first unit test, you must ensure that you have the test and monitor tool add-on installed. To verify this, log into API Manager. The bottom right tile on the home screen should be labeled Test APIs, as shown in the following screenshot:

Figure 13.1 – Verifying that the test and monitor tool is installed

Once you have verified that you have the test and monitor tool installed and available, clicking this tile will open the tool in a new tab, where you will be looking at the tool’s home screen, as shown here:

Figure 13.2 – The test and monitor tool’s home screen

As you will notice when you open the tool for the first time, there will be a current summary of all of your Test Suites, test cases, and other data from past test case executions. Since this is your first time accessing this tool, all of these values will have a zero count.

Before we start configuring these Test Suites and test cases, let’s take a look at the HTTP Client. To access this, you must click the HTTP Client link on the home screen. Once you click this link, you will be brought to the HTTP Client screen. This layout and functionality may look familiar to you as it is similar to other testing tools present on the market today. From this screen, you can submit an HTTP request to any URL using any of the available HTTP methods. The following screenshot shows this default screen as it is presented to you. Here, we have numbered each of the components of interest when you submit a simple request to your API:

Figure 13.3 – HTTP Client

Let’s take a look at each of the fields, options, and buttons that will be of interest to you when you’re generating your HTTP request:

  1. HTTP method: Using the dropdown list in this field, you can select the HTTP method to use for your test request message. The available options are GET, POST, PUT, PATCH, and DELETE.
  2. Request url: This provides the request URL for your API to be tested. Do not add query parameters to this field.
  3. Params: Using this button, you can add query parameters to your request in key/value pairs. As you add these params, they will automatically populate in your request URL.
  4. Headers: Provide any HTTP headers to be sent in the request in key/value pairs. Using the + button, you can add additional HTTP headers to the list.
  5. Body: If applicable, this provides two options for adding a request body to your request. You can provide a raw request body that gives you a generic text area to add your request, or you can choose a URL that’s been encoded where you can provide key/value pairs for your request body.
  6. Send: Use this button to send your request message once all the request fields have been entered.
  7. Response: The response to your request will be shown here once sent.

As you can see, there are more options available on this screen that we will cover later in this chapter. The fields we’ve described already will be the ones you need to generate your first HTTP test message for.

Let’s take one of our fictitious healthcare APIs, called Member API, and send a test request to it. This API has a path for getPatient that accepts an HTTP GET method and requires a query parameter named memberID. This API is secured by a client ID and client secret, so we will need to add these as our request headers. The following screenshot shows our test request containing all of the required information, as well as the response that’s received from the API. Since this is an HTTP GET request, there will be no body to send:

Figure 13.4 – Test request for Member API

Leave a Reply

Your email address will not be published. Required fields are marked *