You can create environments containing the initial values of environment-specific variables to use in your journeys. For example, you may have one set of login credentials on your staging environment and another set for your production environment, while your journeys are the same.
Each project can have as many environments as you need, and you can optionally define the environments such that they inherit defaults from one another (see Inheriting environments).
Environment variables can store files and any value as text (e.g., text, JSON objects, boolean values, numbers, etc.). These values can also be marked as secrets (sensitive information), so they are only shown during creation. This is helpful for storing data such as login credentials or a pdf file with sensitive data.
Each environment may also contain an associated Bridge to be used when running journeys with that environment.
# How to create an environment?
Open the Environments manager page of a project by clicking on the
Environments icon on the left menu:
Create environment and fill the information for your environment:
- Name: A unique name that allows you to identify the environment.
- Description (optional): A short description to allow you to identify the purpose of the environment.
- Bridge (optional): A Virtuoso Bridge to be used whenever the selected environment is also used.
After creating the environment, you can add environment variables to it.
# How to create an environment variable?
Open the Environment manager, select an environment that you want to create the variable in, and follow the instructions below depending on the type of variable you want to create.
# Text variables:
Create variable, fill in the name and value for that variable, and click on
Create variable. In the example, we show the creation of a variable named
username@test as its value.
# File variables:
Add file, fill in the name, select the file for that variable, and click on
Add file as variable. File variables come in handy for test scenarios that require file inputs.
In the example, we show the creation of a file variable named
avatar.png, and this variable can be used in a scenario where an image file is required to be used.
The created variable is shown as part of the selected environment. Clicking on the pencil icon
To make the variable be sensitive click on the switch placed after the value input box. Once created, you can still edit it, but you cannot see its previous value.
# Inheriting environments
You need to have at least two environments to make one of them inherit from the other one. Once you have both environments created, just click on the environment which will be the child, click on
Inherits from, and choose the desired parent environment:
Once you confirm the change, the child environment will inherit all variables from the parent environment. Values defined in the child will take precedence over values in the parent, and values not defined in the child will be automatically updated when changed in the parent environment.
Environment inheritance allows you to define what your tests should use depending on specific environments. As an example we can define a
production environment with the URL of the production application, a username, and a password. Then we can define two more environments:
staging, which inherits from
production and overrides the URL but uses the same credentials and
development which inherits from
staging and overrides the URL and the password.
To achieve the above use case you can create the following environments:
production |__staging |__development
The result for our example would look like this:
productiondeclares the next variables:
productionand only declares the variable
urlto override its inherited value from
passwordto override their inherited values from
# Running a journey with an environment
If you only created a single environment, it's the default environment for your project and it will be used always.
On the other hand, if you have two or more environments, you can choose which one is the default environment for your project:
You can also configure a specific goal to use a different environment. In the goals list, click on
Edit settings in the context menu of a goal and then select the default environment in the "Environment" settings section. If the environment has an associated bridge, it will be shown here.
If you just want to run a specific goal using a different environment once, you can configure it using the "Execute advanced..." option to run the goal or journey, then choose the environment as part of the execution.
If a goal is executed using an environment that is not the project's default environment, the execution job will be tagged with a tag following this format:
environment: <environment-name> (e.g: "environment: development"), so you can filter and locate jobs that used a certain environment.
You can also easily test your journeys while authoring by using an alternative environment configured for the scope of your live authoring session.
# Using environment variables in your tests
The syntax to be used for our NLP parser is
$variableName. Our autocomplete step will suggest to you at the time you start to type the name of one of your variables:
Write $username in field "Username" Write $password in field "Password" Click on "Login"
To use a file variable, you can use the same syntax as above.
Upload $avatar to "Drag an image here"
This syntax is also valid if you want to pass the value of your variable as input for an extension:
Execute myExtension using $myVariable as input
After running your tests, every step that used an environment variable will now have a side effect:
Note that variables marked as sensitive won't show their values: