assertTextPresent(locator,text)

mobile » assertTextPresent(locator,text)

Description

This command searches within current application for all elements that match to the specified locator, and then evaluate if any of these matched element contains the specified text. If any of the elements contains the specified text then this corresponding step is considered as PASS. If no matches can be found - either via the locator or the text parameters - then the corresponding step is considered as FAIL.

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 element(s) to search against
text - the text to match. PolyMatcher supported here.

Nexial Automation

Test Automation Platform for everyone!