Unlike UI tests that need to interact with a browser, API tests are performed at the message layer (e.g. http protocol). Therefore, they run much faster than browser tests, completing in seconds, not minutes.
The mabl API test editor lets you:
Create API steps (requests), including support for variables for chaining requests and doing data-driven testing.
Send API requests and see the response data.
Easily make assertions and create variables based on the response without writing code.
Use JavaScript to add custom pre-request and test logic, including support for Postman functions and its library thanks to the mabl integration with Postman.
Manage variables in the left side panel.
Drag & drop steps to rearrange them.
Run the entire test locally using the "Run test" button.
Use case: You can use the API testing capabilities in mabl to achieve the following:
Augment your end-to-end browser tests to make them more reliable and faster
Quickly and reliably setup/teardown test data that browser tests will rely on
Share data between UI and API tests within the same plan using variables
Increase API test coverage by validating that the APIs meet your expectations for functionality, reliability, performance, and security.
How do I use it?
Configure your environment
Before creating and running API tests, we recommend that you configure your mabl environment by adding a base URL for the API endpoints.
You can do so from the Configuration -> Applications section of your mabl workspace.
This configuration allows you to use a variable called api.url when composing the full URL for your API requests (e.g. /api/users) so that you can easily run the tests across environments such as development, staging, and production.
You can now create your first API test in mabl from scratch or import an existing Postman Collection.
Creating API tests
Open the desktop app, click on the New test button in the left sidebar, and then select create an API test.
Fill out the test creation form and click on Create test.
You will be presented with the mabl API test editor that lets you create a test from scratch or import a collection from Postman.
To import a collection from Postman,
Click on ⬆
Import an existing Postman Collection (JSON file) that contains a set of API requests.
Once you import a Postman Collection, you will see the API requests from Postman have been converted to mabl test steps that you can review.
Note: Ensure that the collection does not have any folder as it won’t work when imported in mabl
To create an API test from scratch:
Click on the ➕ button
Give the step a name
Select the desired HTTP Method
Enter the desired URL and click the Send button.
Note: Variables in API tests do not require @. E.g. /api/users
Save the test.
Creating assertions
By default, mabl will automatically create an assertion that expects the status code to be equal to 200. You can change this assertion or add a new assertion from the Validation and variable assignment section for that API step.
Creating variables
There are two primary ways to create a variable within an API test:
Using the variables panel in the left sidebar
As part of the response validation for a given API request
You will typically use the variables panel to create variables with a default value which you can later override with different values that are passed to the API test from a datatable or from a previous test run within the same plan.
Following the above approach, you can create as many assertions and variables as needed for each step of your API test. Thus, when you run the API test, if one of the assertions fails, then the test run will be marked as failed.
You can easily create assertions and variables based on the following response data:
Status code
Size
Headers
Body
Supported assertion types are:
Equals
Does not equal
Contains
Does not contain
Is present
Not present
Using variables with API tests
Environment variables
If you need to run an API test across multiple environments, you can use environment variables to pass environment-specific variables to an API test. Here is what you need to do:
In the API editor, use the Add variable button in the left side panel to add your variables with a default value that will then be overridden based on the environment
In the mabl app, go to Configuration -> Applications and click on the pencil icon next to an environment name to edit its environment variables. Make sure to use the same variable names as the ones you already defined in your API test.
Now, you can run the API test in the mabl cloud by choosing the desired environment and mabl will use the variable values coming from the environment.
Data-driven testing
You can perform data-driven API testing in a similar way to data-driven browser testing, using variables and a datatable to manage the test data outside of the test. There are three steps to it.
In the API editor, use the Add variable button in the left side panel to add your data-driven variables with a given default value.
In the mabl app, go to Configuration -> Datatables to create a datatable with the same variable names that you used in your API test and assign a value for each variable based on the number of scenarios you want to test.
Go back to your API test details page, click on the pencil icon in the top left to update the test and associate the newly created datatable with it. When you run the test in the mabl cloud, mabl will override the default variable values based on the values coming from the datatable scenario as long as the variable names match.
After you have associated the datatable with your API test, you can use the Run test button from the test details page to do an ad-hoc API test run in the mabl cloud and then select to use the datatable to verify that everything works as expected.
Using JavaScript with API tests
You can handle complex API testing and troubleshooting scenarios using JavaScript code that can be supplied within the following parts of an API test step:
Pre-request script: Code runs before the request is made to execute conditional logic
Test script: Code runs after the request is made to validate response data
