Skip to main content

Using Variables for Environment Flexibility

Legacy Documentation
You're viewing legacy documentation for API Fortress (deployed via an on-premises container). To view documentation for the new SaaS version of API Fortress — now known as Sauce Labs API Testing and Monitoring (with Sauce Connect tunnels) — see API Testing on the Sauce Labs Cloud.

In API Fortress, you do not have to be concerned with organizing variables in a hierarchy from global to local… why?

Almost any string can be hardcoded or referenced as a variable in API Fortress. Hardcoding is fine as long as you’re building simple tests, however, it is advisable to parametrize some items when:

  • The number of tests is increasing
  • The complexity of tests is increasing
  • The number of tested environments is increasing

Most of the parametrization you will likely do relates to the HTTP request itself.

Using the Vault​

While the following variable is perfectly valid, it may become extremely painful to update tens or hundreds of tests if the domain changes.

Hardcoded Variables

Alternatively, you may use the API Fortress Vault to store domain names to solve this problem. Simply add a “domain” variable in your vault as follows:

Domain Variables

And then edit the GET like this:

Parametrized Variables

In this way, you can eliminate duplicate tasks by simply editing the vault variable to instantly update all tests.

Using the Environments​

Once a domain is parametrized, you may override a variable, if needed.

By activating a preset in the environments section, you will be able to hit a different domain in the current session without actually changing the test as in the following:

ENV 2

The same selection can be performed while creating a schedule to create specific runs hitting specific environments.

In Request Bodies​

Variables are not only bound to URLs. Request bodies can also be handled like "templates" when needed, incorporating variables as in:

BODY

And Basically Anywhere

Reference variables almost anywhere that you need. Consider the following example assertion:

EXP

Yes, we're using variables as expected values.

Conclusion​

API Fortress provides the flexibility and freedom to combine the use of global, local, and hard coded variables as you want. In addition, API Fortress also provides helpful hints as you work with variables.

  1. Fill the vault with data that is project-centric: Domains, protocols, API keys. They are all fine. We discourage you from introducing test-specific variables because it would produce an overhead of information that would go unused most of the time.
  2. Fill the globals/input set with test-specific variables, such as paths, IDs, dates, and serial numbers, etc.
  3. Make sure that the “vault + globals/input set” add up to a complete variable scope for the test. In other words, the test should be able to run without further information.
  4. Use the environments to change the values of the variable scope generated by the vault+global/input sets.
  5. Don’t overdo things. Parametrize stuff that can actually change, and leave everything else as static strings. Variables are… well, variable, so an excessive and unnecessary use of variables leads to uncertainty and hard-to-track behaviors.