An action argument can have one of several possible data types.
Once you have defined an argument in an action worksheet, and then checked in the action, the new argument appears as a node in the TestArchitect explorer tree, under the node of its parent action.
By double-clicking an action argument node, the Argument page is displayed in the main panel. On this page, you, or an automation engineer, may assign an argument type to the argument. Depending on what kind of data type is selected, additional modifier fields might be needed to define possible values, ranges or formats. (Possible values for the Argument Modifier field are discussed below.)
Modifications to an argument’s attributes have no direct effect on its parent action’s definition (that is, on the action worksheet). They do, however, allow TestArchitect to assist you at the time of test writing. When you write an action line calling a user-defined action, the editor provides assistance with arguments that have modifier specifications, helping to ensure that the values you provide are consistent with the modifiers. The form of this assistance depends on the type of the argument involved, as discussed below.
In general, while the focus is on an argument cell:
- Press Ctrl + Spacebar. A context list of available, defined values then appears.
- Using the mouse or arrow keys, select a value.
- Double-click, or hit Enter, to insert the selected value into the cell.
This is the default type that is assigned to an argument when it is created. Any value is accepted as a literal string.
Argument Type = String.
When you enter data into an argument field of the Date type, you have the option of either typing a date directly in, or allowing TestArchitect to assist you with a pop-up calendar control. The calendar control is invoked by hitting Ctrl + Spacebar, or by putting the cell into a text-insertion state. (That’s what you’re in when you see the blinking text cursor in the cell). Next, click the triangle button that appears. Once in the calendar control, you may navigate to the date you wish to insert, then simply click it.
The Argument Modifier field of a Date argument allows you to specify the form that the entered date will take. Several formats are available for the date type, using different arrangements of various month, day and year specifiers. The set of available specifiers is as follows:
Allowable delimiters between specifiers are hyphen ( - ), forward slash ( / ), comma ( , ) and space. Delimiters may also be omitted. Hence, some example date formats are:
|mmmm dd,yyyy||december 27,2011|
|dddd,mmmm yyyy||tuesday,december 2011|
A value set is a user-defined set of allowable values, also known as the value domain. In the editor, when you wish to enter data into a cell of an argument of type Value Set, you have access to a drop-down list of all elements in the value domain.
Alternatively, the list may be brought up by double- or triple-clicking in the cell, depending on whether focus is already on that field. You may then select a value from the drop-down list, or type a value directly into the field.
The Argument Modifier field of a Value Set argument is where you specify the value domain. Your modifier may be as straightforward as a simple list
(1, 2, 3, 4, 5), or can involve complex expressions in which the value domain depends on the contents of one or more other argument fields. For example, for a given action, an argument named car model might have different value domains, depending on the existing contents of the car type (
The following syntax rules apply when defining a modifier for a Value Set argument:
- Elements in a list of acceptable values must be comma-delimited.
- To include a comma in a value, encode the entire value in double quotes. For example:
"Obama, Barack", "Bush, George", "Clinton, Bill".
Conditionals, in which the value domains are determined by the values in other argument(s), make use of comparison operators to determine the contents of the value domain:
Table 1. Comparison operators
|4||<>||not equal to|
|4||>=||greater than or equal to|
|4||<=||less than or equal to|
- When a conditional statement is required, the condition and the values associated with that condition must be separated by a colon ( : ). For example:
car type=standard: Monte Carlo, Grand Am, Mustang Coupe
- If there are multiple conditional statements, they are delimited by semicolons ( ; ).
Conditional statements are evaluated from left-to-right. The operative value domain is the one connected with the first conditional statement that is satisfied. Subsequent conditional statements are ignored. For example, assume the following contents of a modifier field for the apparel argument:
temperature <= 40: overcoat, scarf, earmuffs; temperature <= 60: sweater, jeans; temperature <= 80: t-shirt, shorts; temperature > 80: bikini, sandals.
- If the temperature argument holds the value
55, the operative value domain for apparel is sweater, jeans.
- It does not matter that the
temperature<=80conditional is also satisfied, because it appears after the
temperature<=60conditional, which is the first one satisfied.
Each conditional statement may have multiple conditions. These are combined with the logical operators and, or, and not.
Table 2. Logical operators
|5||not||Value is TRUE if its operand is FALSE.|
|6||and||Value is TRUE if and only if both sides of the and operator are TRUE.|
|7||or||Value is TRUE if either side of the or operator is TRUE.|
Parentheses may be used in statements with multiple conditionals, in order to override the default order of precedence.
The asterisk ( * ) may be used as a wildcard to represent any value. This applies to conditionals as well as value set lists. In the latter case, it indicates an open value domain. In the case of conditionals, it is useful at the end of a list of conditional value set expressions, to indicate the default value set (see the table below).
Some further examples of value set modifiers:
|country||Example of a simple value set. Only US, Canada and Mexico are acceptable. All other values are displayed in red in the editor.|
|country||US, Canada, and Mexico appears in the drop-down list, but any other input is accepted (that is, not displayed in red).|
|city||- 2 cities, each are displayed in the list if country is US or Canada.|
- No option is displayed for Mexico, but any value is accepted.
- For any other country, any city value is regarded as invalid (displayed in red).
|zip code||- 3 zip codes, each are displayed if country is US and city is either Los Angeles or Chicago.|
- No other zip code is allowed for Los Angeles or Chicago.
- If country is Canada, any zip code is valid.
- If country is anything else, n/a is the only option.
This argument type is used to pass the name of an interface entity to an action. When an argument has the Interface Entity type, you are presented with a drop-down list of interface entities to choose from. The list includes all interface entities defined in the project.
Additionally, if your project subscribes to any other projects, the list includes interface entities defined in the supplier(s). Entities of the working project are presented in black text, whereas interface entities of supplier projects appear in red.
- Any name conflicts (same-named interface entities existing in both the working project and a supplier project) are resolved in favor of the working project.
- The Argument modifier field is not applicable to arguments of Interface Entity type.
This argument type is used to pass the name of an interface element to an action. When an argument has the Interface Element type, you are presented with a drop-down list of interface elements to choose from. The list includes all interface elements defined in the project.
TestArchitect can be configured so that argument headers and values used in calls to actions can be hidden in the text editor when the values match the defaults defined for the action. You can set this up in the Preferences dialog box:
- Select menu Edit > Preferences
- In the Preferences dialog box, select the Hide arguments using default value check box.
- Click Save.
After setting this option, arguments in action lines that pass default values are hidden in the test editor when you save the file.
An action which can be automated belongs to one of three categories: built-in, user-defined or user-scripted.