Flexible variables for flexible environments

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 be doing relates to the HTTP request itself.

Using the Vault

For example, while this is perfectly legit:

harcodedIt may become extremely painful to update tens if not hundreds of tests if the domain changes.

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:

domainAnd editing the GET like this:

parametrizedIn this way, editing the vault variable will instantly affect all tests.

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:

env2You will be able to hit a different domain in the current session, without actually changing the test.

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:

bodyAnd basically anywhere

Variables can be referenced basically anywhere, let’s take this assertion in consideration:

expYes, we’re using variables as expected values.

However…

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.

  1. 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,
  2. Fill the globals/input set with test specific variables. Such as paths, Ids, dates, serial numbers,
  3. 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,
  4. Use the environments to change the values of the variable scope generated by the vault+global/input sets,
  5. 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.