Parametrizing Tests/en
Inhaltsverzeichnis
Parametrizing Tests[Bearbeiten]
Parameter values (like hostnames, port numbers, user names, DB names etc.) should usually not be used literally as freeze value or hard coded into an elementary block's code, because this may make the suite harder to maintain in that you'd have to search for such values whenever a change is required (using the string search facility in the left tree view).
In almost all situations, it is much better to define an environment variable in the suite's top level environment, preset a value there, and use Environment Freeze Values as input to pins or the "self environmentAt:" API call from within elementary code. Actually, it is even recommended to not refer to environment variables from within elementary code, but instead add another pin to the action block, and freeze the value from the outside. Be reminded, that you can also freeze pins to a default value in the schema definition of an action, so that users of library actions do not have to do so when placing action steps into their activity diagrams (but they still have a chance to change such default values, if they need to).
Every access to an environment follows a scoped outer-environment nesting chain, so inner (compound-action) environments can overwrite or redefine a value, if they desire.
Using Top Level Environments[Bearbeiten]
The top level environment should always provide a reasonable default value for a parameter. Thus, at any place within the suite, a value would be found and provided.
Example[Bearbeiten]
A typical parameter may be an IP-address of some test machine. To add a top-level environment variable for that, navigate to the test suite item (the top level item in the tree), select the "Variable Environment" tab, and add an entry using the "+V" button in the toolbar. Give the variable a reasonable name, datatype (in this case: String), and an initial default value.
Using Local Environments[Bearbeiten]
Let's assume, that you have written a test as an activity diagram, where the above defined parameter is used as a freeze value. And now, this activity has to be executed on two machines in sequence or in parallel, using different IP-addresses. The easiest way to do this is to define two additional wrapper actions, which both contain the single original test, and redefine the variable in their local variable environments with the desired IP addresses. Then put these two actions inside a third new activity, which executes them in sequence (using trigger-out/trigger-in connections) or in parallel (by setting both to autostart).
Using Separate Parameter Sets[Bearbeiten]
By default, parameter values are stored within the saved test suite file (the ".ets" file). However, it is possible to save and load the parameter values separately. For this, navigate to the suite's "Variable Environment" tab, and select the "Other" - "Save Selected Entries As..." to store some parameters into a file. Use the corresponding "Other" - "Load Entries From..." menu item, to load a parameter set from such as saved file. The files are simple XML encoded ASCII files and could be generated by some automatic build process (for example be given by the development team), or edited in an external editor if desired.
Using Command Line Options[Bearbeiten]
A separate parameter file (as described in the previous section) can also be specified in the expecco command line. Use this when expecco is to be executed unattended (i.e. via Jenkins, cron job or batch/shell script).
Loading Parameters from CSV Files[Bearbeiten]
Using a CSV reader action block, parameter files can also be read or written by the suite itself. You can either pass such a reader's output data to environment set blocks, or pass the values directly to input pins of your test action. In addition, complete environments can be read or written via "Environment from File" / "Environment to File" action blocks.
Loading Parameters from a Database[Bearbeiten]
In a similar way to the above, you can also use an ODBC database query block, to read values from a relational database and either feed them to environment set blocks or to input pins of your test action.
