In this module, you will be learning to create your own test from scratch with test components, using requests (such as GET or POST), assertions that check if data exists, and use variables, input sets, and the Vault to store and reuse elements of your tests.
Assertions and Request Components
Variables
The test component library contains many useful test components that can enrich and add further validity to your API Tests. This level covers the basics of components you can add to your API test.
To access the component library:
+
symbol at the top of the Test Composer.All available test components, as well as a search bar, will appear on the next screen.
If you select the Tag component at the top, it will automatically add this component to the bottom of your test, like in this image:
You can add any of the following components to your test, depending on your use case. For an example some examples in the screenshot below:
key:value
store.POST
and PUT
requests.There are many components you can play around with, and hover over them to see what they do, but next you will focus on Request, the building block of every API test.
In this lesson, you will learn to add a GET request component in a test.
A Request component is the foundation for creating a new test in API Fortress. Whether you wish to test a chain of multiple requests, or a single request, the request component is where your test should begin. The available request components are:
Refer to the API Testing Basics module for further details about API request methods.
https://api.us-west-1.saucelabs.com/rest/v1/public/tunnels/info/versions
payload
This is what the finished result should look like:
In the next section, you will work with Assertion components, learning how they are a vital part of your API tests.
There's a common phrase in the automated testing space: "If there is no assertion, it isn't a test." In this lesson, you will add an assertion after the GET request in the Sauce_Connect_Test you created in the last lesson.
This sentence demonstrates a common testing anti-pattern; even if your code doesn't throw errors or crash, it doesn't mean it's a valid test.
In order to validate an API endpoint works properly, you must assert whether the API's expected output is correct or incorrect.
There are several assertions to choose from and below are a few examples, along with the accompanying documentation:
In this example, you will be checking that when you ping the endpoint https://api.us-west-1.saucelabs.com/rest/v1/public/tunnels/info/versions
that a payload is return (it exists) and the one of the fields, the "info_url"
is in fact a url.
If you check the HTTP Client tool, you should see the elements we are checking for:
payload['downloads']
one
payload['info_url
]url
url
.In the next section, we will cover how to store information as a Global Variable.
As the complexity and number of tests in your test suite increase, it's a best practice to name and store test details such as common variables or data sets to allow more flexibility. There are three ways to store data within the API Testing platform:
This lesson covers how to use Global Variables.
API Testing – Global Variables
The global variables (referred to as parameters in our API Testing interface), are usually common variables designed to run with an entire test such as authentication API Key, or a domain name. Global variables can be used across different tests in a project.
To add a global variable/parameter, select the Input tab in the top left, and select Add Global Param.
To begin the exercise, open your Sauce_Connect_Test, navigate to the Input tab on the left side of the interface, and select it.
Select Add Global Param in the Global Parameters section.
Add the following data to the global parameter:
domain
api.us-west-1.saucelabs.com
The parameter now appears in the Global Parameters section.
Next, we need to substitute the domain
value in the current GET request:
saucelabs.com
with the ${domain}
global parameter:protocol
and endpoint
global parameters. The values for the respective params should be https://
and /rest/v1/public/tunnels/info/versions
, respectively.The finished result should look like this:
In the next section, we will cover how to store information as an Input Set.
An input set is an object (usually a group of input variables related to a specific scenario or use case), For example a list of relevant product ids returned from a product API endpoint. In this lesson you will:
When you add and use an Input Set, it means you will run a separate instance of your tests for each Input Set created. For example, if you created three Input Sets for username
and password
, your tests would be run three times, using each set of credentials. Input Sets are used within a single test.
To add an input set, select the Input tab in the top left. If there is a default input set, you will want to edit or delete it before creating your own.
First, click on the Input button on the top left hand side of the test page. Under the Input Set section you create two Input Sets called tunnel_owner_1
and tunnel_owner_2
.
In each of the input sets, add in the following sets of variables:
tunnel_owner_1
owner
xxxxx
tunnel_id
xxxx
tunnel_owner_2
owner
xxxxx
tunnel_id
xxxx
You will replace the x
s with values once you get owner and tunnel ids form the Sauce Labs Tunnels dashboard.
For this course, we will be using Sauce Connect Tunnels. To learn how to start a tunnel, see our Sauce Connect Setup video on YouTube or Module 1 of our Sauce Connect course. You should use tunnels that you own, or shared tunnels you have access to start and stop.
Start at least two tunnels, then go to the Sauce Labs Tunnels page. Get the values for the Tunnel ID and Owner, and replace those values in the Input Sets you created on the API Testing dashboard.
Now, you should have values like this, which match the values on your Tunnels page:
Now, you will create another GET component in your Sauce_Connect_Test that will use the input sets you just created.
This request will use the Sauce Connect API Call to GET Tunnel Information. Add a GET component to your test.
https://api.us-west-1.saucelabs.com/rest/v1/${owner}/tunnels/${tunnel_id}
.scpayload
, where the response will be stored.You will also need to add a Add Authentication (Basic) with a Sauce username and access key for a user who has access to both the tunnels you used in your Input Set.
Now, lets add two simple checks after this get request. Add in two components:
scpayload
variable with the response.owner
variable in an Assert Equals component, one that checks that the owner retrieved from the GET request matches the owner your set for that tunnel.The test should now look like this:
Now, once you save and Run your test, the test will be run one for the input set tunnel_owner1
and once for the input set tunnel_owner2
, a total of four GET commands, since there are two GET commands in each tests.
To summarize, we have created a test that:
In the next section, we will discover how to store some of the information we created in the Vault.
The Vault is a unique feature of the API Fortress platform that allows you to store information for use across all projects or tests.
While Input Sets are typically only used within a given test, the vault allows you to store inputs and parameters that can be used across multiple test in your project. This is known as your Project Vault. In this lesson, you will learn how to:
The Project Vault allows you to save more than just variables; you can also save, edit, and reuse almost anything, including:
First, what is a Code Snippet? A snippet is a fragment of a test, stored in the Vault, that can be reused. For example if you want to re-use an authentication header, or perhaps there's a POST
body value you wish to re-use in multiple requests.
For this example, we don't need both the GET methods in the same test since the first one only needs to be run once (and not for every input set) we will store and re-use this part of the test.
To add the snippet to your project Vault:
SC_Download_Snippet
The snippet now appears in the Snippets section of the project vault. To get back to the vault, go to the Project where your tests are listed and select Vault in the toolbar, then the Code Snippets radial button:
If you wish to re-use this snippet in a different project/test, there are two options: Invoke a Snippet or Insert a Snippet. Invoking a snippet doesn't actually modify your test components, instead it makes an API call to the Vault, which inserts the snippet at test runtime. In contrast, inserting a snippet literally inserts the code into your existing test.
Let's try adding a snippet to an empty test:
You can now remove the first GET component and related checks from the Sauce_Connect_Test.
Now you just need to make sure variables are aligned. Now we reach the dilemma of having to re-create our variables that we used from earlier: ${domain}
, ${protocol}
, and ${endpoint}
. The better approach is to use the Company Vault, which allows us to re-use variables across all projects.
To access the Company Vault
domain = api.us-west-1.saucelabs.com
protocol = https://
endpoint = /rest/v1/public/tunnels/info/versions
The end result should look like the screenshot below:
Now, if you run your new test that you created with a snippet (where you invoked or inserted the assertion snippet), all variables will default to the values in the Company Vault, and you test should run without you having to add new Variables to that test.
If you want to re-use a code snippet across different projects, it's a bit easier than re-creating variables from scratch. You can actually export it from the project vault, into the company vault.
To export a Snippet into the Company Vault:
.csv
is recommended here).This is a screenshot of the end result:
Now you can add this snippet to any test in any project. This approach is much easier than recreating the entire test from scratch! Run your test to see the report.
To learn more about The Vault and Environments, see: