select(locator,item)

mobile » select(locator,item)

Description

This command instructs Nexial to select item from the dropdown component denoted by locator. The specified item must be one of the values in the target dropdown component. Otherwise, the corresponding step will likely fail. Alternatively, one can use the index: prefix to denote an item of the dropdown based on its index. For example,

The above example shows how one can select the 4th option of the dropdown component denoted by ${dropdown.locator}. Note that index value is 0-based (i.e. 3 means the 4th available item from the top).

Consequently, one can use the Nexial function $(random) to derive at a randomized index, thus giving some variation to the execution:

When selecting a dropdown option by its text on an Android device, one may employ PolyMatcher to yield a more dynamic and possibly more resilient automation. PolyMatcher allows one to select a dropdown option based on various matching logic such as “CONTAIN”, “CONTAIN CASE-INSENSITIVELY”, “START WITH”, etc.

Lastly, the locator parameter should represent the component that would trigger the rendering of a dropdown, not the dropdown component itself. Nexial will attempt to find and activate (i.e. click) on the component represented by the locator argument, and then automate the selection of a dropdown option based on the item argument.

PolyMatcher Enabled

PolyMatcher - a flexible way to perform text matching

In addition to extract text matching (or string matching), this command/expression also supports "polymatcher" (as of v3.6). With polymatcher, one can instruct Nexial to match the intended text in a less exact (but more expressiveness) way. Here are the supported matching strategies:

CONTAIN:: Use this technique to perform partial text matches. For example: use CONTAIN:completed as intent for "matching text that contains the text ‘completed’".
CONTAIN_ANY_CASE:: Use this technique to perform partial text matches (same as CONTAIN:), except without considering the uppercase/lowercase variants. For example, CONTAIN_ANY_CASE:Successfully would match "Completed successfully", "Completed Successfully", and "COMPLETED SUCCESSFULLY".
START:: Use this technique to perform "starts with" text matches. For example, START:Greetings matches any text starting with the text "Greetings".
START_ANY_CASE:: Use this technique to perform "starts with" text matches without considering letter casing. For example, START_ANY_CASE:Greetings matches any text starting with the text "Greetings", "GREETINGS", "greetings", "greeTINGs", etc.
END:: Use this technique to perform "ends with" text matches. For example, END:Please try again. matches any text that ends with the text "Please try again.".
END_ANY_CASE:: Use this technique to perform "ends with" text matches without considering letter casing. For example, END_ANY_CASE:Please try again. matches any text that ends with the text "Please try again." in any combination of upper or lower case.
REGEX:: Use this technique to perform text matching via regular expression. For example: use REGEX:.+[S|s]uccessfully.* as intent for "matching text that contains 1 or more character, then either ‘Successfully’ or ‘successfully’, follow by zero or more characters.".
EMPTY:[true|false]: Use this technique to perform "is empty?" check. EMPTY:true means that the target value is expected to be empty (no content or length). EMPTY:false means the target value is expected NOT to be empty (with content).
BLANK:[true|false]: Use this technique to perform "is blank?" check. BLANK:true means that the target value is expected to contain blank(s) or whitespace (space, tab, newline, line feed, etc.) characters or empty (no content or length). BLANK:false means the target value is expected to contain at least 1 non-whitespace character. Note that this matcher includes te EMPTY: check as well.
LENGTH:: Use this technique to perform text length validation against target value. One may use a numeric comparator for added flexibility/expressiveness. For example: LENGTH:5 means to match the target value to a length of 5. LENGTH: > 5 means to match the target value to a length greater than 5. The available comparators are: >, >=, <, <=, =, !=.
NUMERIC:: Use this technique to perform numeric comparison/matching against target value. With this technique, 100 considered the same as 100.00 since both value has the same numerical value. One may use a numeric comparator for added flexibility/expressiveness. For example: NUMERIC:5 means to match the target value to the number 5. NUMERIC: <= -15.02 means to match the target value as a number that is less or equal to -15.02. The available comparators are: >, >=, <, <=, =, !=.
EXACT:: Use this to perform exact text matching, i.e. equality matching. In most cases, this is not required as the absence of any special keyword almost always means the "is this the same as that?" test. However in some special cases such as base » assertMatch(text,regex), one may use this EXACT: syntax to indicate match by equality instead of regular expression.
And, of course, one can still use the exact matching strategy by specifying the exact text to match.

We will be adding new strategy to polymatcher – Please feel free to request for new ones!

Nexial provides 2 wait strategies in regard to locating elements. In both cases, they are configured via the corresponding “profile” and the use of the use(profile) command.

Implicit Wait

The idea of implicit wait is to suspend execution for a specified amount of time before proceeding to finding the target element. The wait time is specified in millisecond.

To specify implicit wait, use the following configuration for your profile: [PROFILE].nexial.mobile.implicitWaitMs=<millisecond>

If this configuration is not specified, the System variable by the same name - nexial.mobile.implicitWaitMs - will be used instead. Specifying this configuration thus override the system default. If [PROFILE].nexial.mobile.implicitWaitMs is specified with a value less than 200 (millisecond), the system default will be used instead. Any wait time that is 200 or less would not likely to be fruitful.

Explicit Wait

Explicit wait is different from its implicit counterpart in that the specified wait time is not exercised prior to finding the target element. Instead, Nexial polls for the target element every 10 millisecond until either the element is found or the specified wait time is passed - whichever comes first. Hence, the specified wait time is the maximum amount of time to wait (i.e. tolerance) before consider the target element as non-existent. This form of wait is generally preferred as the automation generally runs faster and with less flakiness.

To specify explicit wait, use the following configuration for your profile: [PROFILE].nexial.mobile.explicitWait=<millisecond>

If this configuration is not specified, the System variable by the same name - nexial.mobile.explicitWaitMs - will be used instead. Specifying this configuration thus override the system default. However, if [PROFILE].nexial.mobile.explicitWaitMs is specified with a value less than 200 (millisecond), then Nexial will consider explicit wait DISABLED. Consequently, disabling explicit wait would activate implicit wait.

About locators

Note that for mobile automation, there are some differences in locators between Android and iOS devices. Check the the Locator section for the various options of specifying a locator. Unless there are strong justification such as performance lag or platform-specific workaround, the recommendation is to use locators that are common to all mobile devices – namely, ID (id=...), Accessibility ID (a11y=...) or XPATH (xpath=...).

Parameters

locator - the locator of the component that would trigger the rendering of a dropdown.
item - the item (text or index) to select from the rendered dropdown. For index-based selection, use index:... syntax. Note that index is 0-based.

Example

See examples above

Nexial Automation

Test Automation Platform for everyone!