Environment Editor/en

Environment Editor

The environment editor is used to create and edit variables in the environment of a test suite, a test plan or a compound block. In imported suites/libraries, a readonly version of this editor is shown. The view slightly differs when either the testsuite's or a compound block's environment is edited. It can be found on the "Environment" tab after selecting the test suite or a compound block in the navigation tree.

Environment variables can be used as input to a step by setting an input pin's input value (freeze value) to "Read from Environment" via the pin's menu. The standard library also contains a number of blocks to dynamically add, remove, read or modify environment variables.

Environments are arranged as a hierarchy of local environments (lexical scope), so that an inner block's variable may hide an outer block's variable, up to the containing test plan and finally the test suite's environment. By default, an inner variable (i.e. from a deeper nesting) shadows a corresponding outer variable, but this behavior may be reversed for special situations, where an inner variable is used to provide a fallback value for testing.

Buttons

• Add another variable to the environment
• Remove the selected variable from the environment

• Initialize the environment with the given values (only shown in the project's environment). This is done automatically, when a test suite is loaded initially, but may also be needed to reset read/write variables which have been modified by a test run back to their initial state, or to have computed values be recomputed.

• Move the selected variable upwards in the list. As variables are initialized in the order of appearance, this may affect the order of execution of any computed values
• Move the selected variable downwards in the list

Popup Menu Functions (Right-Button-Menu)

The right mouse button shows the following popup menu items:

Undo

undo the last cut/paste operation (inside the variable editor)

Add Variable

add another variable

Cut Variable

remove the selected variable(s). These are put into the clipboard and can bbe pasted at another place.

Copy Variable

copy the selected variabes to the clipboard

Paste Variable

paste the variables in the clipboard

Move Variable To..

to move the selected variables into another environment

Rename Variable...

rename a variable. Searches for uses of the selected variable and renames thpse references too. However, if the name is constructed somewhere, it may not be found. So use with care.

Load Entries from File...

to load a file containing a set of values. The file can be in expecco's native XML format, in JSON or in CSV (i.e. imported from excel)

Save all Entries to File

to save all variables into a file. Specify XML (expecco's native format), JSON or CSV

Save Selected Entries to File

like above, but only the selected variables are safed.

References

search for references to this variable in the suite

More

additional, less frequently used menu items

Move Up / Down

to move the selected variable(s) up/down in the list

Fields

Variable-Name

This field is a text input field that holds the variable name, which must meet the rules for variable naming (alphanumeric or underline character, no embedded spaces). Click it once to give it the input focus.

NET (visible in expeccoALM)

This checkbox determines whether the variable will be visible in expeccoNET or in exported parameter sets. Such externally visible variables can later be provided by whoever initiated the automatic test run (i.e. expeccoALM, another QM platform, an external parameter file or provided as command line argument). This option/column is only shown in the project's variable environment.

MON (monitor variable)

This option is only useful if expecco is used in conjunction with certain versions of expeccoALM. It defines the variable as a monitored variable. Such variables send out change notifications in realtime, which can be monitored by the QA platform (currently: only expeccoALM supports this).

OW (overwrite)

This check box determines whether the variable hides (overwrites) an inherited variable from an outer scope, or not. This option/column is only shown for compound blocks. The default mode is "overwrite", so variables behave as if defined in a lexical scoped fashion: variables can be redefined in a compound block to overwrite any outer definition of the same named variable.
The non-overwrite mode is useful if a block wants to define a variable's fall back or default value, to be used if no outer definition exists.
For example, an interface block which needs a port number (for example: HTTP Port) might define the variable as a non-overwriting local variable, with a value of "80". If an outer block or the test suite needs a different parameter, it is free to define HTTP Port with another value.

R/W (read/write)

This field is a check box that determines whether the variable can be modified during initialization, or not. Parameter values should be set to read only, which is the default for new variables.

Datatype

This drop down list provides a list of available data types. Choose the type of the variable here (typically, most likely a String- or Integer type is used)

Initialization

This drop down list provides a list of possible initialization methods for the variable's value. Most common are Constant and New Instance, but it is also possible to assign a value during initialization by evaluating a programmatic expression, or to request values from the user via a dialog. See list below.

Initial Value/Expression

Use this text field to enter the initial value (if the initialization method is Constant).

Current Value

This field shows a variable's current value. This information is useful for writable variables (for example: counters or other measurements as gathered during execution) or for user-entered variables. Notice, that the top-level test suite environment is initialized one, when the suite is loaded, so you may have to manually reset modified counters if stored in the global environment, if the suite is executed multiple times.

Initialization Types

Notice that variables are only initialized once, when the environment itself is instantiated. The instantiation happens at load time for the top-level project environment, or with every execution for the test suite, test case and action environments.

The concrete behavior, depending on the init-type, is:

Constant

a constant value, such as a port number, counter values, host name or other simple (unstructured) values. This value is used "as is". You may refer to other variables by name or the operating system's shell environment variables using a $-prefix: use "$(Name)" to refer to the value of the variable named "Name". The parenthesis are required. Thus if your environment contains a variable "Foo", with value "Hello", the value "$(Foo)World" will expand to "HelloWorld" whereas "$Foo World" remains as is.

Be careful when referring to variables from within the same environment, because they are initialized top-to-bottom, and the values of variables further down the list will not yet be setup. In addition to the shell's variables, such as "$(USERNAME)" and "$(PATH)", a few additional pseudo variables are accessible:

$(AttachmentsDirectory) - the directory where all of project's attachment files are located (by ID, not by name)

$(ProjectDirectory) - the temporary directory where all of the project's files are located. This directory will be removed when another project is loaded, or expecco is terminated.

$(ExecutionDirectory) - the temporary directory where temporary files during a single test execution are located. This directory will be removed after the execution.

$(ExpeccoInstallationDirectory) - the directory where expecco is installed.

$(ExpeccoPluginDirectory) - the directory where expecco plugins are installed.

SecretConstant

like above, but its value is not shown in the variable-environment; useful for passwords. Notice: the algorithm for password storage is not secure. It will be easy for any experienced user/programmer to extract these values from either the saved test-suite or via an inspector from the running test-suite. Also, the value might also be visible in the execution log, if it is passed as String through input/output pins.

New Instance

creates a new (empty) instance of the data type.

New Instance of Size

given its size in the environment, create a vector (collection-like) instance.

Ask for Size

will ask the user for the size of an instance to create.

Request from User

opens a dialog to ask for the variable's value, when the project is loaded. You can define the dialog box's question title in the comment.

Request from User when first used

opens a dialog to ask for the variable's value, when the variable's value is needed for the very first time during the session. If the value is never needed (because the block(s) which need this value are not executed), no question dialog will be shown during execution. You can define the dialog box's question title in the comment.

Secret from User

like "Request from User", but hides the password in the dialog, and only displays '*'s in the value fields.

Secret from User when first used

like "Request from User when first used", but hides the password in the dialog.

Smalltalk Expression

the text is evaluated as a Smalltalk expression and the resulting value used to initialize the variable.

JavaScript Expression

as above, but uses JavaScript syntax for the evaluation.

GUI-Value

a special type used with GUI blocks.

GUI-Action

a special type used with GUI blocks.

The "when first used" initialization-type is useful for passwords of dynamically alternative execution paths - for example, if your test suite needs either an FTP- or an HTTP password, depending on which communication path is chosen dynamically.

---

Copyright © 2014-2024 eXept Software AG