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.
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:
In Request Bodies
Variables are not only bound to URLs. Request bodies can also be handled like “templates” when needed, incorporating variables as in:
Reference variables almost anywhere that you need. Consider the following example assertion:
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.
parametrization, pass values, pass variables, header variables, body variables