This topic describes how to configure and work with different environments. In this section:

Understanding Environments

Environments are collections of variables that can be referenced within fields of your responder or action suite, as well as your test configurations.You can use environment variables to specify endpoints, database table names, connection properties, such as login credentials, and so on. The names of variables will be substituted with the assigned values in the active environment. By switching which environment is the "active" environment, you can dynamically switch the environment-specific values at runtime.Environments can also be used to switch virtual asset modes. For example, assume you configured a responder to forward traffic to an external endpoint. By using an environment variable for the endpoint (instead of a fixed value), you can easily redirect message forwarding to different endpoints. This allows .pva files to act like proxies; one environment can point to a real asset while another points to a virtual asset.Environments are automatically defined when you generate a Parasoft asset from a definition, such as WSDL, but you can also manually define environments as described below.

Manually Defining an Environment

Creating and switching environments is done through the Environments branch of the test suite's Test Case Explorer or Responder suite's Virtual Asset Explorer node.

The Environments branch is created by default when a new test suite or Responder suite is created.

To add a new environment:

  1. Right-click the Environments node and choose NewEnvironment.
  2. Rename the environment (optional) and click on a field in the table to define environment variables and values. 

Masking a Variable Value

You can right-click on a variable and choose Mask Variable Value to hide the value in the interface.

Masking a value prevents the REST Client from showing the resolved value.


If Masked Environment Variables is enabled in your preferences (see Miscellaneous Settings) or misc.hide.masked.variables=true in your settings file (see Configuring Settings), masked environmental variables will also be hidden from traffic viewers, REST Clients, JSON/XML Data Banks and Assertors, and in the Event Monitoring Details.

Using Environment Variables in Tests and Tools 

Environment variables can be accessed in test or tool configuration fields using a special syntax. To reference a variable, enclose the variable name in the following character sequence: ${env_name}.

For example, if you had a variable named HOST, you would reference the variable in a field by typing: ${HOST}. Variable references may appear anywhere within a field.

You can access Environment Variable values from an Extension Tool/Script through the Extensibility API. ExtensionToolContext now has a method called "getEnvironmentVariableValue(String)" which will look up and return the current value of an Environment variable. This will allow you to use the value within your scripts.

Note

If your test case or tool requires the character sequence ${}, you can escape the sequence by adding a backslash. For example, if SOAtest or Virtualize encounters the value "\${HOST}" it will use the value "${HOST}" and will not try to resolve the variable. Also note that environment variable names are case sensitive.

Changing Environments from the GUI

To change what environment is active, right-click the node representing the environment you want to make active, then choose Set as Active Environment.

Changing Environments from the Command Line

In addition to being able to select the active Environment from the GUI, you can also switch the active environment from the command line, using the -environment option.  See Testing from the Command Line Interface - soatestcli for details.

Overriding Environments Using Test Configurations

To set a Test Configuration to always use a specific environment for test execution (regardless of what environment is active in the Test Case Explorer), set the Test Configuration’s Override default Environment during Test Execution option in the Execution tab. See Execution Tab Settings: Defining How Tests are Executed for details.

Sample Usage

Let's say you are developing a service on your local machine. Once the code works locally, you commit the code to source control and start a build process targeted to a staging server. You want to create a suite of tests that will test against both your local machine and the staging server with minimal modification. This is the perfect case for using SOAtest Environments.

Begin by creating a localhost environment for your new .tst file. The SOAtest New .tst Wizard will get you started with a few basic environment variables. If your WSDL varies across the two machines, you can decompose the WSDL URI into variables. If the WSDL location is constant across the machines, you can alternatively decompose the endpoint URI.

The next step is to identify other machine-specific settings in your projects and to create environment variables for them. For example, let's say you have a JMS step in your test suite and you need to send the message to different queues depending on whether it's a localhost test or a staging test. First, create a new environment variable, let's call it "JMS_REPLY_QUEUE". Next, revisit your SOAP Client, go to the JMS settings, and enter ${JMS_REPLY_QUEUE} as the value for the JMSReplyTo field.

Once you have created your localhost environment, you can copy and paste the existing environment and rename the new environment to "Staging Environment". Then, simply modify the values of each of the variables so that they reflect the settings of your staging server.

Once your environments are setup, targeting your tests against the various environments is simply a matter of selecting the active environment. If you wanted to test against your local machine, you would set your active environment to be "Localhost Environment". This will run your tests using the values defined in the localhost environment. To test against the staging server, set the "Staging Server" environment to active and its values will be used.

Exporting, Importing, Referencing, and Editing Environments

You may find that many configuration settings, such as server names and ports, will be common across multiple projects. Rather than duplicating these settings, you can export environment settings to an external file and import or reference the values in other projects.

Exporting Environments

To export an environment:

  1. Right-click the node representing the environment you want to export, then choose Export Environment.
  2. In the file chooser that opens, specify a location for the exported environments file.

The environments configuration will be written in an XML-based text file. If one Environment is selected, a *.env file will be created, containing a single environment. If multiple environments are selected, an *.envs, or Environment Set, file will be created containing all of the selected environments.

Importing Environments

When you import environments, you are bringing a copy of the values from the external environment file into your project. Further modification to the XML file will not be reflected in your project.

To import an environment:

  1. Right-click the Environments node, then choose Import Environment.
  2. In the file chooser that opens, specify the location of the environments file that you want to import.

Referencing Environments

Referencing environments is the most efficient way to share a single environment configuration across multiple projects. Using environment references, you can easily modify the configurations of multiple projects from a single location.

To reference an environment:

  1. Right-click the Environments node, then choose Reference Environment.
  2. In the configuration panel that opens on the right, specify the location of the environments file that you want to reference.

Note that when an environment configuration is referenced, you cannot edit the environment variables in the environment directly. However, your project will always use the values reflected in the referenced *.env file. Modifying the *.env file will propagate changes to all projects that reference it.

Editing Environment (.env) Files

Environment (.env) files are XML-based text files and can be edited manually. It is not recommended that you try to create an .env file from scratch; instead, export an environment as described in Exporting an Environment to use as a template. After exporting an environment, you can open it in any text editor to make changes. It will look similar to the sample below.

Sample .env XML
<?xml version="1.0" encoding="UTF-8"?>
<Environment xmlns="http://www.parasoft.com/schema/environment/1.0"
             name="New Environment">
   <Variable>
      <Name>Name1</Name>
      <Value mask="false">Value1</Value>
   </Variable>
   <Variable>
      <Name>Name2</Name>
      <Value mask="false">Value2</Value>
   </Variable>
</Environment>

Existing variables can be edited directly. To add a new variable, copy an existing variable (everything between a set of <Variable></Variable> tags, including those tags) and paste on a new line, then change the name and value as needed. Note that masked values should not be modified manually, nor should you attempt to create a masked value manually; work with masked values in the UI only.

  • No labels

Need assistance? Visit our support page