Below are the primary learning objectives for this module:
Assertions and Request Components
The test component library contains many useful test components that can enrich and add further validity to your API Tests.
To access the component library:
+symbol at the top of the Test Composer
All available test components, as well as a search bar, appears 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 example:
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.
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.
Negative : In the previous module, Introduction to API Fortress, we used the Generate Test button. This button automagically generates the HTTP request, assertions, and other test elements so that you can focus on the more intricate and tricky parts of your tests. In this module we will build a test from scratch in order to understand the importance of assertions, but refer back to that test for inspiration and ideas on how to design your assertions.
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." The previous 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 the next section we will cover how to store information as a Global Variable, or an Input Set.
As the complexity and number of tests in your test suite increase, it's a best practice to parametrize test details and data to allow more flexibility. There are generally two ways to store data within API Fortress:
The global variables (referred to as parameters in the API Fortress 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 Set tab to the right of the interface, and select Add Global Param.
An input set differs from a global parameter in that it is usually a group of input variables related to a specific scneario or contextual use case—for example a list of relevant product ids returned from a product API endpoint. Input sets are used within a single test.
To add an input set select the Input Set tab to the right of the interface, and select Input Set.
Navigate and select the Input Set tab on the left side of the interface to begin the exercise.
Next we need to substitute the
domain value in the current GET request:
uriglobal parameters. The values should be
Negative : Please refer to the documentation for further information on using variables.
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. While Input Sets are typically only used within the same test or project, the vault allows you to store things that can be used across any project.
The Vault allows you to save more than just variables, with the vault you can save, edit, and reuse almost anything including:
In the Vault, you can store data at three different levels: scope, project, and global. At the project level the vault will allow you to reuse those values across any test within that project scope. Similarly, the global level allows use of stored values across any test within any project.
Negative : If you plan on re-using code snippets from the Vault, make sure those variables remain consistent across each test. Also note that if you add an input set or global parameter with the same name, those values will override what is saved in the Vault.
To add a snippet to your account.
+icon next to Snippets:
quick test to store snippet in the vault
Negative : In order to delete a snippet, select Vault in the top menu, find the project where the snippet is stored, and click on the snippet to access the trash can icon.
If you wish to re-use this snippet in a different project, create a new empty test, and open up the Vault menu on the side. Choose the bottom element in your test, and click the arrow to either invoke the snippet, or to copy and paste the component:
Now you just need to make sure variables are aligned:
The finished result should be identical to your previous test:
This approach is much easier than recreating the entire test from scratch! Run your test to see the report.
Access the Vault and add variables and code snippets by first clicking on the Vault in the main menu.
From here you can access and edit code for snippets:
Or access and edit variables for both global project-specific snippets and variables.
To learn more about The Vault and Environments see below links: Learn the Basics, Environments Basics, Using Variables