Validating Android Toast Messages with Appium

     As we know that Android Toast is a small message displayed on the screen, similar to a tooltip or other similar popup notification. A Toast is visible for a short time period. If you’ve used Android apps for any length of time, you’ve no doubt noticed these little notifications that pop up and fade away with time.

     Of course, toast messages can prove a challenge for automation. From the perspective of the Android Accessibility layer, toast messages aren’t visible! If you try to get the XML source from an Appium session while a toast is present on the screen, you won’t find its text anywhere. Luckily, with the advent of the Espresso driver (don’t forget to use the capability caps.setCapability(“automationName”, “Espresso”);), we have the ability to match text against on-screen toasts. In this article, I would like to share how it all works.

      Once the toasts message showing up, we need a way to check what they say for verification. Unfortunately, we don’t have a method for getting the text from a toast message. What we have instead is a method that takes a string and tells us whether the on-screen toast matches that string or not. This is enough for our purposes of verification. So let’s check out how to use the mobile: isToastVisible method:

ImmutableMap<String, Object> args = ImmutableMap.of(
“text”, “toast text to match”,
“isRegexp”, false
);
driver.executeScript(“mobile: isToastVisible“, args);

     Like all mobile: methods, we first need to construct a map of our arguments. This method takes two parameters: the text we want to look for, and a flag which tells Appium whether this text is in the form of a simple string or a regular expression. Finally, we call executeScript as a way of accessing the mobile: method.

     As we know that toast messages are a time-sensitive phenomenon. So we probably want to start looking for a matching toast before it pops up, so we’re sure we don’t miss it. To this end, we can use a custom Explicit Wait. It’s possible to use the Java client’s ExpectedCondition interface to define our own custom expected conditions. Here’s a helper method that defines a new ExpectedCondition and you can use this method in your automation script to match the toast message.

public static ExpectedCondition<Boolean> toastMatches(String matchText, Boolean isRegexp) {
return new ExpectedCondition<Boolean>() {
@Override
public Boolean apply(WebDriver driver) {
ImmutableMap<String, Object> args = ImmutableMap.of(
“text”, matchText,
“isRegexp”, isRegexp
);
return (Boolean) ((JavascriptExecutor)driver).executeScript(“mobile: isToastVisible”, args);
}

@Override
public String toString() {
return “toast to be present”;
}
};
}

     All we do is override the appropriate methods of the ExpectedCondition class, and ensure we have appropriate typing in a few places, and we’ve got ourselves a nice self-contained way of waiting for toast messages, in conjunction with (for example) WebDriverWait. In reality, you can use the following snippet format within your test script to validate the toast messages in Android,

WebDriverWait wait = new WebDriverWait(driver, 10);
//Application should generate the toast message
wait.until(toastMatches(“simple toast message”, false));
wait.until(toastMatches(“regular expression of toast message”, true));

     We define a WebDriverWait and use it with our toastMatches condition. You can see that we perform a match with both available modes, first by matching the exact toast string, and secondly by using a regular expression, highlighting how we could verify the presence of a valid toast message even if it contains dynamically generated content. Try to use the above code snippet along with your Android automation to validate the toast messages on the screen.

Reference: Appium Pro

make it perfect!