Using Test Fragments

How does this benefit me?

If you have written a lot of tests, chances are that you have come across cases when you have had to use the same set of steps in multiple tests. For example, you may require authentication for your API requests, and thus need to call an authentication API to obtain a new token in each of your tests. You may also need to perform some processing after obtaining the token to prepare the data for an API call.

When programmers write code, they face a similar case, where they need to utilize the same lines of code in multiple places. This is handled by making those lines of code modular (e.g., using functions), where it is written once and then called in multiple places that need it.

At RapidAPI, we apply the same principles of modularization to API Testing through Test Fragments. That is, Test Fragments allow you to define a set of test steps once, and call those steps in multiple tests that need them.

How do I use it?

We accomplish test modularization in RapidAPI by allowing a test to be called by other tests. Let us walk through an example by using the authentication use case.

For simplicity, we will assume that our authentication involves two steps. First, calling the /token endpoint. And then, create a string “JWT_token=<token_from_step1>”. And these are the authentication steps that need to happen in every test.

Create the Child Test

We would first create the child test; that is, the test that we will “call” in our other tests. It is simply a regular test, with the two steps in it. See below for illustration. Because this is a regular test, you can also add assertion steps if necessary.

Calling the Child Test

Now that we have created the child test, we want to utilize it in other tests. We are going to create a second test, and name it “Get Products”. As a first step, we want to call the authentication child test we have created earlier in order to obtain a token. We can do that by using “+Add step”, and selecting “Execute Child Test”.

We now have a step in our new test called “Execute Child Test”. We need to give it some information so that it knows what to do.

• First, we will select the child test that we want to use. In this example, we selected the “Authentication” test that we have created earlier. See #1 in the image below. Note that only tests within the same API can be leveraged as a child test.
• We want to access all the output variables generated within the child test. We will do this by entering a desired variable name in the Variable field. In this example (see #2 in image), we will name it “authToken”. All the variables in the child test are scoped under authToken and are accessible from the parent test through {{{authToken.*}}} nomenclature.
• As an example to #2, if I want to use “fullToken”, I can access it by using {{{authToken.fullToken}}}. See #3 in image. For refreshers on how to insert variables with braces, see here.
• For convenience, once you select a test, you can easily see the child test definition by clicking the link icon (see #4 in image).

That is it! At this point, we have defined a child test, called the child test from a parent test, and used values generated by the child test in the parent test.

Providing Input Variables

Similar to how functions work in code, there are instances when you want to pass input variables to the child test. We will walk through an example on how to do this in RapidAPI Testing.

In this example, we will use a test called Get Product as the child test. The test performs a GET request for a specific product, and performs several assertions. We also want the child test to take a product ID as an input to be used in the GET request.

In order to accomplish this, we will first add the product ID as a test variable in the child test, and then use the test variable in the GET request.

Now, we will call the child test and pass a product ID as an input variable. We can do this through the “Variable Overrides” section of the “Execute Child Test” action. Each input in the Variable Overrides section is a key-value pair, where the key is the name that we used in the Test Variable (a dropdown will help you select), and the value is the new value that we want to use to override.

When the test is executed, it will use the value we pass here as product ID (that is, 212313), as opposed to the value we defined in the Test Variable of the child test (12345).