get setting
| Name | Description | Type | Modifier |
|---|---|---|---|
| name | Name of an existing built-in setting or a user-defined setting. | Value Set | case sensitive, ignore blank space, etc. |
| type | Type of this setting. Allowable values:
| Value Set | built-in, user defined |
| variable | (Optional) Name of the variable to receive the returned value. | String | None |
| default | (Optional) Value to which to set the variable if the specified setting has no value. (Applies only to user-defined settings - See ) | String | None |
Example #1: Reading and setting user-defined settings
Let's say you have a set of tests for an application that is primarily targeted at the English-speaking world. You want your tests to default to English, but you also want to be able to launch entire test runs for testing other language versions of the application.
You could do this by establishing a user-defined setting, which we'll call language, in the Startup Settings panel of the Execute Test dialog box. On any given test run, set this setting to the language of your choice.
Since our tests will default to English, in order to have them perform their testing in English, you have the option of setting the above value to English, or simply clearing it.
Since there are a lot of various messages and user interface bits of text that are used by our tests, and which will vary by language, we use an ODBC database (one that TestArchitect's
database actions
can work with), to store the translations:
Each test module of the project is initialized with a get setting action that writes the test language to a variable, current_lang. With the default argument set to English, we are assured that, if no value has been set for language in the Startup Settings, current_lang will be set to English.
Next, a user-defined action, connect to language database, handles the minutiae of connecting to and using the database with our translations_table. The execute sql action following it issues a query that retrieves all of the translations in the table for the given language, writing them out to a single data set row.
Now that we have all the translations we need, the first test case demonstrates how they are used. Another user-defined action, log in user, attempts to log in to the AUT with a wrong password. Upon return, we check for a message from the AUT indicating that the login was invalid. Assuming, for instance, that the test run was launched with language = German, the data set field msg_invalid_login holds the value, "ungültiger Benutzername oder Passwort" (the German equivalent of "invalid username or password"), and that is the message that is checked for.
Action lines
name type variable default
get setting language user defined current_lang English
 
connect to language database
 
command result
execute sql # "select * from translations_table where lang = " & "\"" & current_lang & "\"" translations_ds
 
name
disconnect database lang_db
uname pword
log in user john bad password
 
window control value
check car rental message message # msg_invalid_login
Example #2: Reading built-in settings
The get setting action allows your test procedure to determine the value of a built-in setting and take action accordingly. Say, for instance, that your test needs to interact with an HTML element that is treated differently by different browser types. In that case, it is helpful to know which browser you are interacting with, and your test can determine this by reading the current state of the use browser setting.
One example is the HTML5 input element with a type attribute of color:
<input type="color">
In Internet Explorer, however, the same element/attribute combination is merely rendered as a text box, in which the user must type in the hexadecimal RGB values for the desired color:
On a window intake, the TA class that TestArchitect generates for this element/attribute combination depends upon the host browser. Hence, you might want to have two separate interface elements in your interface entity for this control, one with the correct TA class for Chrome and FireFox, and the other with the TA class for IE. Beyond that, your test procedure needs to interact differently with each type of control.
In the example below, the use browser setting is read into variable browser in use by action get setting. The variable is then used in the
if structure to determine which interface element to use. In addition, user-defined action select color might also read browser in use to branch to the correct set of system-level action lines for interacting with the control.Action lines
name type variable default
get setting use browser built-in browser in use
location window handle
navigate www.paintonline.com
 
condition
if # browser in use = "Chrome" or browser in use = "Firefox"
 
name value
global variable colorpick control chrome colorpicker
 
condition
else if # browser in use = "Internet Explorer"
 
name value
global variable colorpick control ie colorpicker
 
end if
 
window control color
select color paint online # colorpick control dark red
- default argument:
- Built-in setting: For a built-in setting, any value in the default argument is ineffectual, because TestArchitect enforces the rule that all built-in settings always have a non-empty value.
- User-defined setting: If no value is defined explicitly in the Execute Test dialog box (or in the /startupsettings parameter in the case of command line or batch execution), the value of the default argument is assigned to the variable. In this way, individual test modules or user-defined actions may be allowed to, in effect, determine the value of a given setting.
- Note that the same functionality offered by the get setting action is also available from the getsetting function or, if you are writing a user-defined script, from the GetSetting method.
Tel:
Email: