Skip to content

Variables

A Variable holds data that can come from a number of data sources. It is intended to reuse data across test hierarchies and elements.

We distinguish:

Test definition Variables

Test definition Variables can be assigned to these four test definition elements, sometimes referred to as holder types

  • Repository
  • Testset
  • Testcase
  • Teststep

Variables view

The Variable views have all the same structure they just differ in the variable type and their parent type.

You have several commands for working with variables. To get started, let's discuss the different variable types.

variables overview

Variable types

String Arbitrary Text. String variables are used in a variety of cases, such as query data from a response or randomize value providers.

Password Any text. This types hides the value in the variable list view and during edits and be undisclosed on demand

Absolute Date: Enter a static date to reproduce tests. The Variable Editor provides a convenient way to enter the date and formatting for the service call.

Relative Date: Creates a date relative to the current date. On Test runs, this relative date is re-evaluated .This allows you to enter a date of birth or a date of manufacturing and make sure the webservice under test will always calculate the same age.

Number: Numbers need a specific formatting when sent in a request or response. This formatting is provided for variables of type number

Boolean Booleans have 0 / 1 values. The variable editor allows use of true/false or yes/no as text for the boolean values.

Create a Variable

There are two places, where you can create Variables, most of the time, you will create Variables from the create new Variable button, which you can see in the screenshot above.

Access Variable values

Variable placeholders are simply substituted by their current values, just like a makro. Variable values can be used in these contexts:

  • SOAP/HTTP Requests
  • URLs of the SOAP Request
  • XPath expression for Assertions and ValueProviders
  • XQuery expressions for ValueProviders

Variable access syntax

  • Teststep variables: $(Teststep.<variablename>)
  • Teststep variables: $(Testcase.<variablename>)
  • Testset variables: $(Testset.<variablename>)
  • Repository variables: $(Repository.<variablename>)

Example for a JSON-payload that uses variables on the current Testcase:

{
    "policy": {
        "startdate":"2025-12-02",
        "paymentmode":"annually"
    },
    "policyholder":{
        "birthday":"$(Testcase.birthday)",
        "address": {
            "street":"$(Testcase.thoroughfare) $(Testcase.subThoroughfare)",
            "postalCode":"$(Testcase.postalCode)",
            "location":"$(Testcase.locality)"
        }
    },
    "car" : {
        "make": "$(Testcase.Make)",
        "model":"$(Testcase.Model)",
        "firstregistrationdate": "$(Testcase.Construction start date)-01-01"
    }
}

Run environment Variables

As described in Run Environment you can configure authentication for a Webservice in a Run Environment Configuration. Data that is configured here, will be accessed, when the user selects the corresponding Run Environment. When you want to access these information within your request, you can provide these values through Run Environment Variables, as described here:

Authentication type Textfield name Variable notation in Test definition
HTTP basic Authentication HTTP username $(EnvironmentConfig.httpUsername)
HTTP basic Authentication HTTP password $(EnvironmentConfig.httpPassword)
HTTP bearer Authentication HTTP bearer token $(EnvironmentConfig.bearerToken)
None (No HTTP authentication) Payload username $(EnvironmentConfig.payloadUsername)
None (No HTTP authentication) Payload username $(EnvironmentConfig.payloadPassword)
None (No HTTP authentication) Payload OTP $(EnvironmentConfig.payloadOTP)
None (No HTTP authentication) Payload Token $(EnvironmentConfig.payloadToken)

We want to illustrate this specific variable resolution mechanism with the example of a sample request that needs to provide a username, a password, an OTP (fixed) in the Test Run Environment and a Token variable, that is retrieved from another request ) We configure a Service Definition for the local Run Environment with NONE-Authentication which means we will use an Idenity Service and pass over data.

screenshot Run Environment Authentication Config

The relevant input is highlighted in blue, you will notice the variable value for the payloadToken information. We will pass the four information in an HTTP request (which could be a SOAP request as well. We have set the Run Environment to localhost. Notice the Repository variable with name token.Our request looks like this:


screenshot Run Environment Authentication Reference

Now, we switch to the tab resolvedRequest to see what the variables are resolve to:

screenshot Run Environment Authentication Resolved Reference