In API Fortress, almost any string can be hardcoded or referenced as a variable. Hardcoding is fine as long as you’re building simple tests, however, when:
- The number of tests is increasing
- The complexity of tests is increasing
- The number of tested environments is increasing
It is advisable to parametrize some items. Most of the parametrization you will likely do relates to the HTTP request itself.
Using the Vault
For example, while this is perfectly legit:
Using the vault to store domain names is a good way to solve this problem by simply adding a “domain” variable in your vault as in:
Using the Environments
Once the domain is parametrized, no one stops you from overriding the variable, if needed.
By activating a preset in the environments section as in:
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:
Variables can be referenced basically anywhere, let’s take this assertion in consideration:
The platform not only provides you the flexibility but also the freedom to basically combine everything as you want.
With that said, we would also provide you some hints on how to get the best from your experience.
- Fill the vault with data that is actually project-wise. Domains, protocols, API keys. They are all fine. We discourage you to introduce test specific variables in here because it would produce an overhead of information that will be unused most of the time,
- Fill the globals/input set with test specific variables. Such as paths, Ids, dates, serial numbers,
- Make sure that vault + globals/input set make up 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. 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.