Expressions, like variables, may appear in action line arguments in TestArchitect test modules and actions. An expression is any combination of literal values, variables, operators, and functions that follows a set of rules, and which needs to be evaluated before it can be used.Operators are symbols which specify operations to be performed, such as addition (a numeric operation) or concatenation (a string operation). (Functions are discussed in Functions.) Evaluating an expression means performing all the specified operations on the operands (the values, variables, and functions) until a value is produced. An action is invoked only after all the expressions in its arguments have been evaluated.
As a general rule, TestArchitect treats the contents of an argument literally – that is, as either a numeric or string constant. To get an argument to be treated as an expression, you must precede its contents with the “#” symbol, which we call the expression indicator.
Note that the expression indicator is required even for arguments that contain nothing more than a single variable. (Think of a single variable as a single-operand expression.) In essence, any time the contents of a cell need to be evaluated before they can be used, they are an expression in TestArchitect’s view.
Exception to the requirement of an expression indicator: While the expression indicator is generally required for an argument that contains a variable, it should not be used for arguments in which a variable name is explicitly expected. That is the case for arguments that the called action is expected to return a value to. An example would be any of the built-in get… actions:
window property variable
get window property login title logtitle
These actions have no need to evaluate the variables, as their only purpose is to assign values to them. (One exception is the case in which a variable or argument holds the name of the variable you wish to write to, which is typically with case for user-defined actions that return values.)
window property expected
check window property car tally title \# Cars
Within an expression, the TestArchitect interpreter tries to resolve every non-numeric symbol to a variable, operator or function. Hence, to specify a literal string within an expression, enclose it in double quotation marks.
Also note that TestArchitect parses expressions by treating spaces and other symbols as delimiters. Because variable names may contain spaces and other symbols, it is necessary to enclose such complex variable names within single quotes, to direct the interpreter not to parse them.
The following set of action lines indicates some of the rules that the TestArchitect interpreter follows:
11 variable value
12 set variable a 5
13 set variable b 8
14 set variable a + b 123
17 report a + b
18 report #a + b
19 report #"a + b"
20 report #'a + b'
Upon execution of the above, the results reported are as follows:
|a + b
|Contents of the text argument are treated literally, since there is no expression indicator (#).
|The expression indicator (#) causes the interpreter to parse the expression into the addition of variables a and b.
|a + b
|Double quotation marks within an expression allow its contents to be treated as a string literal.
|In an expression, single quotation marks surrounding a string that would otherwise be parsed, cause it to be treated as a single symbol (that is, a variable name).
A cell expression consists of two classes of items: operands, which are things that are operated on (such as numbers, strings and variables), and operators, which specify what operations are to be performed. TestArchitect offers seven operators: six that operate on numbers and one that operates on strings.
The following expression operators are available in TestArchitect.
Table 1. Expression operations
|real number division
Note the Precedence column in the above table. All things being equal, expressions with multiple operators are processed from left to right. However, as you (hopefully) learned in grade school, not all operators are created equal: some have higher precedence, or priority, than others. For instance, the expression
4 + 3 * 2, if processed from left to right, would produce a result of 14. But we all know that standard mathematical rules dictate that the multiplication operation be processed first, so that the expression evaluates to 10.
The priority assigned to operators tells us which operations are performed before others. Within a group of operators of equal priority, operations are performed from left to right.
Parentheses can be used to modify the order of operations in an expression. For instance, if we want the expression above to have its addition operation performed first, we need only surround the term with parentheses:
(4 + 3) * 2.
In general, numeric operations and functions are performed on numbers, variables holding numbers, and functions that return numbers. Similarly, string operations and functions operate on string literals, variables holding strings, and functions that return strings.
That said, TestArchitect does allow for string operations to be performed on numbers, and vice-versa, as long as the data type of the operand can be converted to what the operation expects.
In general, performing string operations on numeric operands is no problem: any numeric value can be converted into a string. This allows for the mixing of data types in operations. So, for example, the following set of action lines:
local variable Fords 23
local variable Toyotas 14
local variable Buicks 28
local variable revenue 7234.38
report #"We rented " & (Fords + Toyotas + Buicks) & " cars this month, with revenue of $" & revenue & "."
results in an output of: We rented 65 cars this month, with revenue of $7234.38.
By contrast, converting strings into numeric values is not always a sure thing. For automatic conversion to take place, the string must “look like” a number to TestArchitect. Looking like a number means that it must consist of only the characters 0-9, plus zero or one decimal points, plus an optional minus (-) sign preceding it. If an automatic string-to-number conversion is attempted on a value that does not meet TestArchitect’s criteria, an error is reported in the results.
During an editing session, entering the # symbol in an empty argument cell triggers an autocomplete pop-up window containing a list of variables thought to be within scope at that position in the action lines. Use the Up and Down arrow keys to select one, should you need it inserted at that point. You can bring back the pop-up list at any further point in the expression by pressing Ctrl + Space.
The variables listed in the autocomplete window are purely suggested variables. The editor cannot be certain that the variables it suggests will always be in scope at that point in the test run. It is up to you to ensure that a given variable inserted in an expression will indeed be visible (within scope) when the test is run.
Actions can be written to return values to test modules or actions that call them.