Skip to content

Run Environment

A Run Environment is a logical set of services, applications and configurations that companies use for their software development process to promote development artifacts step-by-step from the local developer machine to production.

Examples of a Run Environments

  • A local developer machineo

  • An integrated test environment that developers use to test their components in combination with other connected services, applications and components.

  • A business test environment that business experts use to test software against their business requirements

  • A load and performance test environment>

  • A staging environment with pre-production data

Typical properties of Run Environments

When you develop or test webservice, you will need to run these tests against several run environments. Some companies may have one or two Run Environments, others may have five to ten. The crucial part of testing is to work with different settings for these Run Environments while keeping the Testcase definition stable.

  • URLs will be different for Run Environments

  • Authentication information may vary , from no or Basic authentication in lower environments, to token or MFA based in higher environments

  • User information for authentication may vary. Users in lower environments may be exchanged by production-similiar users in higher environments.

Run Environment Variables

Run environments can hold a list of variables with specific values for the run environment. You may want to use different request parameters for a developers' test environment than for a business test environment or staging environment. Run environment variables are resolved for: - requests and - urls The syntax to referencing them in your test definition is pretty simple: $(EnvironmentVariable.). A Run environment variable name must be unique for a Run environment,the list editor will mark duplicate entries as duplicate key in the name column.

Run Environment variables list

There are two actions available:

  • add a new Run Environment variable
  • delete selected Run Environment variables for this Run Environment

Use Run Environments for your teststeps

Typically you start by importing or creating a service definition (WSDL, Manual HTTP Service). These service definition hold in general all information that are independent of Run Environments.

You might have a list of Service definition like in the screenshot below: list of endpoint service definitions

You may need to handle several Run Environments like in the next screenshot:

list of Run Environments You would proceed in the following order:

  • You create Run Environment Service Definitions i.e. you define the environment specific properties for your Service Definitions

  • You link your SOAP and HTTP-Teststeps to Service Definitions to use your Run Environment Service Definitions

  • You pick a Run Environment or run a Test execution and run your tests

We will walk through each of these steps below:

Create a Run environment

Switch to the view Environment and click the Button New Environment

Screenshot Sidebar and empty content view for Run Environments

This will open a sub dialog where you enter the name of the new Run Environment. Confirm with OK

Screenshot Dialog new Run Environment confirmation

You will see a new entry, which you select to configure the RunEnvironmentServiceDefinitions, if appropriate. You do this, if you want to switch easily between Run Environments and have predefinition URL and authentication settings. Screenshot Run Environment Service Definition View

We configure the first Manual HTTP Webservice Definition as follows:

Screenshot /Run Environment Service Definition sample configuration

With this, we can proceed with the last two remain steps in the TestDefinition View:

We create an HTTP Teststep and link it to the Manual HTTP Service Definition

Create a HTTP Teststep with a Service Definition Reference

We can use Run Environments for Teststeps that reference a Service Definition. For SOAP Teststeps this is a mandatory step during creation and mandatory for WSDL-based schema validation, for HTTP Teststeps this is an optional step and very helpful.

We switch to the View Service Definition and create a HTTP Teststep that references the My HTTP Service Service Definition.

Screenshot Testdefinition with HTTP Teststep

We select the Run Environment Time Travel and open the configuration details for teststep, we are done now. Authentication and base host URL information are kept centrally and referenced only. screenshot configuration details for Teststep

We can focus on the teststep specific parameters like HTTP Method and a specific route under test, see more about Create an HTTP Teststep and Create a SOAP Teststep.