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.
While the following variable is perfectly valid, it may become extremely painful to update tens or hundreds of tests if the domain changes.
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:
And then edit the
GET like this:
In this way, you can eliminate duplicate tasks by simply editing the vault variable to instantly update all tests.
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:
The same selection can be performed while creating a schedule to create specific runs hitting specific environments.
Variables are not only bound to URLs. Request bodies can also be handled like "templates" when needed, incorporating variables as in:
And Basically Anywhere
Reference variables almost anywhere that you need. Consider the following example assertion:Yes, we're using variables as expected values.
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.
- 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.
- Fill the globals/input set with test-specific variables, such as paths, IDs, dates, and serial numbers, etc.
- 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.
- Use the environments to change the values of the variable scope generated by the vault+global/input sets.
- 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.